C convenience lib (was Re: Is dbus_pending_call_set_notify() thread safe?)

[Daniel P. Berrange]

On Wed, Aug 01, 2007 at 06:15:28PM -0400, Havoc Pennington wrote:
> Hi,
> 
> Fan Wu wrote:
> > I'm wondering if it's possible to stuff most of the dirty works into a
> > background thread, and wrap the thread with some APIs. Users of the
> > API need to supply callbacks to handle various events (just like gbus,
> > but go one step further). If the application has its own mainloop,
> > they can supply its own notifier callback and data(the handle/fd of a
> > pipe/event), or just save this step, and leave the job of notifying
> > mainloop to other callbacks if they feel necessary. The basic idea is
> > these APIs are the ONLY interface to DBUS client and DBUS will hide
> > the internal handling of thread and socket. Users shall not feel torn
> > when making the mainloop/threads decision.
> 
> I'm not sure I understand what you mean here.
> 
> The fundamental issue is this: the main loop is inherently a per-thread 
> global thing, because you can only poll() or WaitForMultipleObjects() on 
> one set of stuff per thread.
> 
> As a result all code running in the same thread must agree upon the list 
> of stuff to be poll()'d and have a way to add/remove items from the poll()
> 
> And this "agree what to poll()" mechanism is the main loop.
> 
> There is no way around that. For a method call, you can either:
> 
>   1) just block on the dbus connection, which will prevent anything
>      else in the same thread from running
> 
>      a) do this in the main thread, hanging the app
>      b) do this in a dedicated per-method-call thread, not hanging the
>         app
> 
> OR
> 
>   2) add the dbus connection descriptors to the list of stuff that the
>      thread will poll(), i.e. add the connection to the main loop,
>      which allows the thread to block on multiple things at once
>      such as the GUI and also the dbus connection
> 
> libdbus already supports your choice of 1)a), 1)b), or 2).
> 
> 1)a) requires no work from the app but locks up the app.
> 
> 1)b) requires the app to be multithreaded and thread-aware.
> 
> 2) requires the app to do some work to integrate DBusConnection into the 
> application main loop.
> 
> So all three are a bit sucky for apps using raw libdbus.

But at the same time, the ability to choose between which of the three best
suits my application's needs is precisely why I'd use libdbus directly rather
than a binding. Perhaps each of these can be made a little simpler to use,
but doubt that's all that much scope without sacrificing flexibility.

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|