tevent_loop_set_nesting_hook deprecated?

[tridge at samba.org]

Hi Simo,

 > The problem is not just being hard to debug, I personally don't see
 > semi-async code much harder to debug then fully async, actually I don't
 > feel any difference.

I can only assume that is because you have mostly worked at the
library level. When creating a protocol library, fully-async is
definately the way to go.

For an example of where fully-async makes less sense than semi-async,
have a look at the SAMR server in Samba4. Look at the various
dcesrv_samr_*() functions. Now look at what functions are called in
there that could potentially block. All of the samdb ones for a start,
plus all of the kerberos authentication ones, and all of the id
mapping ones, and any functions that call any of those.

Imagine how we might recode dcesrv_samr.c to be fully async. It is
certainly possible, but would it gain anything at all? Would it make
the code easier to read? My guess is the resulting code will be pretty
much inpenetrable and unmaintainable whereas the current code is
actally pretty clear.

It also gets worse as library calls that are currently synchronous are
made async. For example, the ldb_msg_*() calls are current
synchronous, but if we want to do them all properly we may need to do
schema introspection at some stage in ldb_msg_*() calls. That would
make them async. So then we'd need to recode all the places that call
ldb_msg_*() to be fully-async. The same goes for tdb calls. Currently
tdb is synchronous, but it may make a lot of sense at some stage to
change tdb to be async, and take advantage of async IO. Do we then
re-code every place in Samba that makes a tdb call to be fully async?

What about configuration. Currently we assume lp_*() calls are
synchronous. They could natually be made async as we want to support
storing the configuration in ldap. So we then recode every routine
that makes a lp_*() call to be fully async?

The key difference between code like SAMR, which naturally uses the
semi-async model, and code which is natually fully-async, is that the
SAMR code is not inherently concurrent. Something like our NBT
library, or the inotify code, or the oplock code is all inherently
concurrent. Using semi-async for that is a bad idea as it just hides
the natural concurrency.

For code that is not naturally concurrent, like the SAMR server, we
will gain nothing and lose much from having a policy of deprecating
semi-async.

Each has its place. When I first started on the event model in Samba4
I thought we should aim for everything to be fully async. I then
realised exactly what we were letting ourselves in for, and realised
it would be a never ending and pointless battle. So now I think that
semi-async is a better solution for code that is not inherently
concurrent.

Cheers, Tridge