[PATCH] tevent-glib-glue

[Ralph Böhme]

Hi Noel,

sorry for the delay, had two days off.

On Thu, Mar 14, 2019 at 05:15:07PM +0000, Noel Power wrote:
> Which brings me to the glue code itself, 
> 
> some minor typos
> 
>     - * We already have a tevent fd event fort the glib GPollFD, but we
> may have to
> 
>     + * We already have a tevent fd event for the glib GPollFD, but we
> may have to
> 
> 
>     + * Fetch glib event sources and attach corresponding tevent events
> to out tevent
>     -  * Fetch glib event sources and attach corresponding tevent events
> to our tevent

fixed. Thanks!

> in tevent_glib_update_events we can get timeout = -1 and if we do we end
> up doing
> 
>      microsec = glue->gtimeout * 1000;
> 
> which is probably not what we want to do, I suppose we need to ignore
> such a timeout and *not* create a tevent timer for it

oh, that creeped in when I simplified that function. Thansk for spotting this! Also fixed.

> However I think there may be some problems with the general approach
> here. For example the prepare, poll, dispatch only happens in the
> context of glib tevent handlers.
> 
> So taking for example a server say WSP (and probably mdssv) that will
> initially establish a connection with the tracker process, this along
> with calling samba_tevent_glib_glue_create will set up the initial glib
> glue tevent handlers that it will monitor.
> 
> WSP server will also set up non glue glib tevent to monitor a pipe for
> communication from a client (using standard samba apis) When reacting to
> the client requests these will happen in the context or a normal (non
> glib glue) tevent handler, this handler will further call glib tracker
> api(s) (for example to initiate a new query and retrieve results).
> 
> The problem I see is that if this glib tracker api results in any
> changes to the set of glib fd(s) or timeouts that need to be monitored
> then the glue code may not be aware of these changes (because the
> prepare phase is only called from glib glue tevent handlers) See
> attached async_tracker.c patch which attempts to fake these scenarios. [1]

ah, finally got it. :)

This should be addressed in the attached patchset. I'm basically taking you tevent tracepoint approach with some simplifications.

I've also added tests to the testsuite that cover both cases: adding a new glib event source from a glib event handler as well as adding one from a tevent event handler.

Updated patchset attached.

CI: https://gitlab.com/samba-team/devel/samba/pipelines/52336817

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tevent-glib-glue.patch
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190318/f785ab2f/tevent-glib-glue.patch>