tevent_loop_set_nesting_hook deprecated?

[tridge at samba.org]

Hi Metze,

I notice you marked the new interface tevent_loop_set_nesting_hook()
as deprecated. It is a bit of a strange idea marking a new
interface as deprecated :-)

I presume you marked it as deprecated as you would like to discourage
new semi-async code. That doesn't really make sense though, as the
caller of tevent_loop_set_nesting_hook() isn't semi-async, it is just
adding code in case some other routine is semi-async. It is needed
because vfs_unixuid changes the global state of the process (the
euid/egid/groups) and that doesn't fit with other code that may depend
on a particicular value of state state (ie. depend on us running as
root).

I also don't think it is realistic to want Samba to never have any
semi-async code. The particular case that triggered the addition of
tevent_loop_set_nesting_hook() demonstrates how hard it is to make
everything completely async. To make it async, all internal calls in
all of the VFS layer would need to be fully async to cope with the
possible calls to winbind. That is a pretty big overhead for something
that is really a non-issue.

semi-async code is not evil. It is a heck of a lot better than
non-async code, and the only real downside to semi-async code is that
the order of completion of multiple outstanding semi-async calls is
the reverse order the calls were made with. 

The existance of a semi-async call does nothing at all to harm
full-async code. The full-async code can continue to operate
completely correctly in the presence of any number of outstanding
semi-async calls, so the only routines that can be adversely affected
by semi-async calls are themselves. This is much better than the
non-async approach that we will be left with if semi-async is
deprecated. If a non-async call is made, then everything else
stops. That should indeed be avoided, and if you want to deprecate
that then I'd fully support you. Deprecating the much better solution
of using semi-async makes no sense to me.

Cheers, Tridge