[RFC] [WIP] tevent/glib integration

[Noel Power]

Hi Metz,

thanks for the comments
On 16/12/15 14:08, Stefan Metzmacher wrote:
> Hi Noel,
>
> very interesting work! It would be really good to have this
> problem solved cleanly in future.
>
> However while reading the patches the first time, I have the feeling
> that the approach adds a lot of complexity and yet another layer
> of abstraction.
I suppose after looking at this (my own mess) for too long probably it
seems actually simple enough conceptually :-)
>
> We used to have integration into a glib/gtk mainloop in the other direction
> See the following link to the historic source:
>
> https://git.samba.org/?p=samba-gtk.git;a=blob;f=common/gtk_events.c;hb=4129587eda424b80225db06c12815414f1c17888
>
> That approach used the glib mainloop as master and was designed for gtk
> applications
> using our client libraries.
>
> I think doing it in the other direction (where tevent is the master)
> is also possible even without modifying the core tevent code!
sure, to begin with I only poked around with the tevent library as I
though that that is what the smbd daemon was doing, I didn't realise
there was a custom 's3' backend, but there seemed merit in having a
generic solution so I decided to see if there was any stomach for it and
leave what was there
>
> Instead we can use a tracecallback and hook into the
> TEVENT_TRACE_BEFORE_WAIT (and maybe TEVENT_TRACE_AFTER_WAIT)
> events.
>
> For samba this could be done within smbd_tevent_trace_callback().
>
> In order to make this more generic we could add a helper function
> which can be called in a TEVENT_TRACE_BEFORE_WAIT hook.
ok, I saw this and thought (as the name suggests) that this was some
infrastructure for tracing (for performance?) I didn't look further at
it. IIUC you are suggesting to use this infrastructure to call out
before (and after) the poll (basically using these to replace my
'prepare_poll & check_poll" methods, is that what you mean ?
>
> This function would maintain some metadata, it needs an array
> of tevent_fd pointers and old array returned by g_main_context_query()
> and have a 2nd array to get the new g_main_context_query() result.
> Then it uses this information to work out which tevent_fd pointers need
> to be added/modified/removed.
sure I already considered better ways to maintain the fds to monitor
(instead of throwing them away each iteraration) but that's just a
boring implementation detail ;-) more interesting to try and get things
to work the easiest way possible
>
> Instead of using g_main_context_default(), we should make use of
> g_main_context_new(), g_main_loop_new() and
> g_main_context_{push,pop}_thread_default()
>
> See the current spotlight code.
> https://git.samba.org/?p=samba.git;a=blob;f=source3/rpc_server/mdssvc/mdssvc.c;hb=HEAD#l1807
actually this is precisely what I wanted to avoid, the
g_main_context_new(), g_main_loop_new() & friends, wrapping existing
calls with g_main_context_push|pop_thread_default, iterating with
g_main_context_iteration. The idea is that you can use glib/gobject
library calls as is and tevent will just take care of the rest e.g. you
call tevent_loop_wait and things work just as if you called g_main_loop_run
>
> Does that make sense to you?
well IIUC the part about using the existing TRACE stuff to avoid
changing the tevent api then yes, however the parts above about using
g_main_loop etc. don't make sense to me

thanks,

Noel