[PATCH] tevent glib event loop glue

[Noel Power]

On 23/02/16 00:24, Jeremy Allison wrote:
> On Mon, Feb 22, 2016 at 07:19:36PM +0000, Noel Power wrote:
>
>> Well, I'd like to ask we hold off committing this (at least until the
>> attached patches are evaluated), I've discovered an issue that leads me
>> to believe that the current implementation wont work. I've come to the
>> conclusion that actually going back to the idea of using trace callbacks
>> is probably the only viable solution. The main problem with the current
>> solution is that if any glib event sources are modified/created/deleted
>> in the context of a tevent handler that isn't associated with the
>> integration implementation then we don't pick up any of those changes
>> (see first patch that modifies the client for a reproducer) This problem
> Can you explain this a little better please ?
Ok, to integrate glib code into an external loop a number of steps are
required and glib provides hooks and a recommended sequence to call
those steps in order for the integration to work.  Please see
https://developer.gnome.org/glib/stable/mainloop-states.gif and
associated blurb
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html

In a nutshell... a glib loop composes of the following steps

1. some initialisation.... then
2. prepare
3. poll (any poll function, the previous step provides the required
timeout and fds)
4. check
5. dispatch

and loop back to  2, 3, etc.

the current integration code tries to do this but in a roundabout way by
hooking into the existing flow of a tevent loop, it works (almost) but
has a flaw, in simplistic terms the tevent loop with glib integration
works like this

1. some initialisation (which additionally calls glib prepare) then
2. poll (including and glib related fd(s)
3. dispatch
      3.1 if glib related source (e.g. fd, timeout, immediate event)
          3.2 check
          3.3 dispatch
          3.4 prepare

and loop back to 2, 3 etc.


the flaw is that in (3) if this is a normal (e.g. not related to glib)
tevent source that fires that in turn calls some glib code that triggers
either activity in existing glib sources (or creates new ones) then we
miss the 'prepare' step that is needed to feed the poll function. The
easiest, safest way to avoid this is just to follow the suggested flow
and do the prepare step 'before' loop_once and the the dispatch & check
'after' loop_once, it is (although a little ugly) the easiest & clearest
way to do this, imho it simplifies the code. If it is considered that
the use of trace callback api in this instance is illegal or just too
ugly then I would just say pump this directly into the s3 event loop in
source3/lib/events.c and forget about being generic.
>
> The patch seems to defer processing the callback
> by interposing an immediate event.
>
> What is the purpose of that ? What use case does
> this test ?
this is quite simply just to fake an external call into a running loop,
consider it trying to emulate the following scenario;

    a. A server has started is ready to serve tevent and glib related
activity, first thing it does (because this test is focussed on
tracker-sparql) is to connect to tracker, that works no problem...
    b. Sit in the event loop and wait for something else to happen
    c. Client calls to server and asks to run a query, so substitute the
immediate event in the patch for an client i/o event,  in other words
the im event in this case is just emulating an external (out of loop)
call into server code
    d. Server code runs the query.... (unfortunately currently it never
processes any replies from that query)

Hope that answers the question ?

Noel