[RFC] [WIP] tevent/glib integration

Noel Power nopower at suse.com
Wed Dec 16 15:30:07 UTC 2015

Hi Ralph
On 16/12/15 14:42, Ralph Boehme wrote:
> Hi Noel,
> On Wed, Dec 16, 2015 at 12:44:16PM +0000, Noel Power wrote:
>> I started experimenting with trying to integrate glib with tevent,
>> specifically my goal is to be able to use tracker-sparql asynchronously
>> without the need for funky polling or iterating mechanisms.
> I'm all ears! :)
> As far as I understand it after just briefly reading this and checking
> the code, we extract the relevant fds from glib and feed the into
> tevent which does the polling, right?
more or less correct, tevent will perform the needed 'prepare', 'query'.
'poll', 'check' and 'dispatch' phases that glib requires each iteration
of it's poll function
> I guess moving from collecting the fds dynamically in every tevent
> loop iteration can't be changed to something more static that simply
> uses tevent_add_fd() to feed the glib fds into tevent?
well we can do better than throwing away the fd(s) and grabbing new ones
each time, we could/should do like Metz suggests compare the old to the
new and modify the fds that poll will use (and I thought about doing
that but decided to keep things simple until more clarity and
discussion.... and I admit...... lazyness)
Using tevent_add_fd directly won't work because GLIB wants to know (or
at that's what the api says) about POLLHUP and POLLERR and also because
you need to acquire the glib_context and hold it for the *entire* [1]
'prepare', 'query'. 'poll', 'check' and 'dispatch' phases you need (or
at least I could see no better way) than to call either side of the poll
function. There are also potential issues with threading and perhaps
even a mutex should be grabbed either at that start and end of the
'prepare', 'query'. 'poll', 'check' and 'dispatch' phases
>> p.s. Ralph I *really* hope you are interested in this and would be
>> willing to test this against your spotlight stuff
> you bet! This is *really* great stuff Noel, thanks! It has a few rough
> edges
hah! understatement
> , but I'll definitely give it a spin over the christmas
> holidays. :)
cool, I would have tried to modify your stuff but I wouldn't be able to
exercise the code (don't own any expensive 'fruit', I would have
modified my own except that I need to do far too many changes before I
could do that. The only thing I did test was running some async tracker
code (actually a version of the example code in async-tracker.c from the
patches ) every time that I got a wsp message in my own server and it
worked fine


More information about the samba-technical mailing list