[RFC] [WIP] tevent/glib integration
rb at sernet.de
Fri Jan 29 09:11:18 UTC 2016
On Thu, Jan 28, 2016 at 05:58:36PM +0000, Noel Power wrote:
> On 28/01/16 14:38, Ralph Boehme wrote:
> > in the meantime I've updated the branch with more polished commits and
> > some performance enhancements (avoiding talloc where possible) and
> > also added a few simple torture tests.
> > I've also added patches to so mdssvc RPC service (Spotlight) makes use
> > of it: this is a significant cleanup and enhancement.
> > Latest patchset attached. I'm not sure this is the final version yet,
> > but it's close, so at this point I'd appreciate a closer review. Thanks!
> I tried to run the example with the lastest branch, but some weirdness there
> a) tevent_glib -t hangs for me
> b) tevent_glib -t -d0 works but is dog slow
> e.g. about X 10 times slower than it used to be
> c) tevent_glib -g is similarly slow ... you changed something in the
> example ? looking at it I didn't see anything obvious beyond superficial
> I looked at the integration code to see if I could see anything obvious
> wrt the hang and saw I think an issue with the handling of the zero
> timeout case, I tweaked it a bit and it seems to solve the hang (see
> attached patches), the one changing tevent_glib_glue_create is added for
> completion (and I am not sure if this case is possible)
ah, no I understand where this is breaking. Good catch! Thanks a lot
for spotting this.
I've prepared a patch is supposed be squashed into the main patch if
you can verify it fixes the issue. The patch can be found on top of
the previous patches in my git branch.
I've taken a different route that you did in your attempt though, as I
realized that we not to prevent to much astraction leaking. I'm now
simply scheduling an immediate event for 0 timeouts.
Can you please check whether this fixes the issue on your system? It
works on mine.
Some comments on your patches:
> Subject: [PATCH 1/4] tweak comment
Updated the comment to be correct and more verbose.
> Subject: [PATCH 2/4] tevent_glib_process can result in tevent_glib_prepare
> leaving with 0 timeout
This should be fixed by the immediate event.
> Subject: [PATCH 3/4] if timeout == 0 signifies there are no fds we need to
> poll then don't
This is very likely not correct as timeout == 0 doesn't imply there
are no fds ready, it merely implies that in the opposite case (no fds
ready) there is very likely a different event source type ready
(timer, idle, signal, ...). But either way, we can't skip the fd
> Subject: [PATCH 4/4] Ensure tevent_glib_process called when
> tevent_glib_prepare results in 0 timeout
This should be dealt with by the immediate event as well.
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
More information about the samba-technical