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

[Fan Wu]

Hi Havoc,

I really want to see this problem "there will be some main loop and
someone doing dispatch" has a off-the-shelf solution. Mainloop is bad
since you need to touch the low level socket, this is a problem if
your existing mainloop does not use poll/select (in Windows people are
more likely to use WaitForMultipleObjects). So you end up working
on/maintaining at least two pieces of mainloop code which is the case
with Qt.

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.

One requirement of achieving this is that the DBUS thread must be able
to be waken up in select/poll sleep. Otherwise the thread has to do
frequent polling which is not desirable for handheld devices.

The major concern I have is, the callbacks have to be thread safe,
which might be hard to do it right.

I may miss major points. Please comment.
Thanks,
Fan


On 7/31/07, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
>
> Fan Wu wrote:
> > I understand your concern of convenience API. But I think right now
> > there is market for easy to use, lightweight C bindings of libdbus.
>
> I do agree btw, but I want to see someone really take this on rather
> than feature-creeping libdbus in a haphazard way. I already feel bad
> about most of dbus-bus.h.
>
> I recently posted that "gbus" git repo, and the header file in there
> shows what I think are some of the most interesting convenience features
> to have. That sketch of an API uses GLib, but doesn't do any data
> marshaling / type conversion stuff and really only uses GLib for the
> main loop.
>
> One problem is that without deciding on the main loop vs. threads
> question, and which main loop if using a main loop, it's kind of tough
> to make a genuinely convenient API.
>
> However, it's possible something like that "gbus" rough sketch could
> just assume "there will be some main loop and someone doing dispatch"
> and that would be good enough.
>
> At that point perhaps it makes the most sense to cram most of the
> convenience functionality there into libdbus itself, to avoid another
> copy of the libdbus underpinnings (DBusString, main loop hooks,
> dbus-sysdeps.c)
>
> If we did this, the only extreme pain in a plain C app using no binding
> would be setting up the main loop.
>
> It probably adds only 20-30K to libdbus and with so many people using
> raw libdbus it might be worth it.
>
> If someone ran with the basic concept of just doing a small API that
> made the common operations a bit easier and implemented introspection, I
> think it would be very popular.
>
> Any takers? :-)
>
> I don't claim to know the perfect balance of bindings and libdbus and so
> forth here, I would encourage experimentation and trying stuff out.
>
> Havoc
>
>