tevent_loop_set_nesting_hook deprecated?

[tridge at samba.org]

Hi Simo,

 > Same feeling here.
 > 
 > Processing more than 1 event at a time is a recipe for madness
 > timeout handling is not the only thing that go bonkers, think of an
 > event that triggers a change in configuration,

processing more than 1 event at a time is called concurrency. That is
what we are aiming for here. Yes, it's hard, and yes, it's hard to
debug. 

Non-async code is easy to debug. That is what Samba3 uses, and its
great, as long as you don't mind losing concurrency.

Fully-async code is very hard to debug and makes for extremely verbose
code where the async handling dominates the code. The current ldb code
is a good example of this. It is great to do fully async when it is
worthwhile and high degrees of concurrency are expected.

semi-async code is much simpler, as it allows the mainline code to
continue in a non-async fashion. It can just call a routine (such as a
winbind lookup) and wait for a result. It is definately harder to
debug than non-async, but it is also much simpler to code than
fully-async.

If we are going to set the standard as "full-async or bust" then the
project is doomed. The whole code base will end up like the ldb code,
with most of the code handling the manipulation of callbacks.

Is it hard to debug? sure it is. So is fully-async code. So is every
concurrency system I've ever worked with. Concurrency is damn hard to
do right.

 > If that happens within a nested event you then have to go to great
 > length to assure the calling event is not dependent on the
 > configuration you are changing.

the same is true of any concurrency system.

 > Other risks are also excessive nesting, I guess on modern linux systems
 > the stack is deep enough to allow for a lot of nested events, not sure
 > about other platforms though.

nope - stacks on all modern systems are growable. It's one of the
fundamental things you get with a virtual memory system. You can
artifically limit the stack size with calls like setrlimit, but there
is no fundamental reason why a stack can't grow as large as the heap.

I'd also claim that stack recursion usually leads to less memory usage
than the constructed recursion you get in async callbacks. 

There are good reasons for not using the semi-async approach in many
cases, but this treatment of it as radioactive is just silly.

 > I fully agree, if you decide to go async, than so be it, make the code
 > fully async.

for library calls, sure. For all the mainline code like the VFS? We
should be fully async for the main async logic (such as blocking file
io, notify events, oplocks etc), but to make every possible blocking
point fully-async will just make the code inpenetrable.

Cheers, Tridge