nested event loops in top level code

[Andrew Bartlett]

On Thu, 2012-06-07 at 02:12 +0200, Michael Adam wrote:
> Hi Jeremy,
> 
> I apopologize for the length of the mail up front.
> But I have been sitting all night over it, elaborating some
> thoughts...

> Detour: view from inside samba

> The use of nested event loops in samba4 is a design that some agree
> should be changed. But it will not happen very soon because it
> will be non-trivial to do and require a lot of effort. So when the
> merge project creates subsystems in the base directory these
> subsystems often contain the potential to create nested event
> loops, when they originate from source4/.  


> it would be best to instead have an obvious and foolprof
> protection mechanism that would forbid s3 to use the base
> libraries in a way to allow for nested event loops.

I just want to put this concern to rest, so it doesn't distract from the
rest of the discussion.  I am not aware of any nested event loops called
from source3 code, with the exception of ldb calls made on private event
contexts (with no connection the client fd) in the _samba4 plugins we
use for s3fs.

It's actually easy to check.  As far as I'm aware, you can't get a
nested event loop without calling tevent_loop{,once}() 

A simple grep shows that the only instance of this call outside test
code, tevent itself, ldb and source{3,4} is:

git grep -n tevent_loop 

libcli/nbt/nbtsocket.c:491:
             if (tevent_loop_once(req->nbtsock->event_ctx) != 0) {

This code isn't linked into the autoconf build, so can't be called from
source3 anyway.  In a sense this validates you concerns, but also it
looks like an ideal candidate for a rewrite to fully async semantics,
given it is low level socket-handling and base protocol packet handling
code anyway. 

So where do the nested event loops really bite?  The biggest issue at
the moment is in gensec_gssapi with the gss_update() loop.  We need to
get this out-of-process.  (This is also not used in the source3 code,
gensec_gse_krb5 doesn't replace the gss socket handler).

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org