slow at samba.org
Mon Mar 18 10:55:23 UTC 2019
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
> 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. 
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.
Ralph Boehme, Samba Team https://samba.org/
Samba Developer, SerNet GmbH https://sernet.de/en/samba/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the samba-technical