Raw libdbus dispatching

[Havoc Pennington]

Peter Clifton wrote:
> 
> It currently "seems" to work if I dispatch one message before the
> mainloop blocks. (If I don't dispatch messages there, things just don't
> get sent and dbus stops working for the app).
> 
> Still, if there are two or more messages in need of dispatching, I
> dispatch one, then let the mainloop block, am I just relying on X-events
> etc... to break the block before DBUS can continue?

Yep. If the dispatch status is not COMPLETED that means there's data 
already read from the socket, so said data won't wake up a poll().

> Is that risky... I
> could dispatch _all_ dbus messages before the mainloop blocks, I just
> didn't want it to starve the mainloop (there is a comment about that in
> the glib bindings).

In glib a GSource need not have an associated file descriptor, i.e. each 
main loop iteration dispatches one message, but as long as the source is 
saying it has more to do glib is not going to do a blocking poll(). So 
in effect glib does dispatch all pending messages before blocking, but 
it allows other sources to run in between each message.

> Can dbus_connection_dispatch() block?

It won't block on its own, but it does call the application handlers for 
each message, and those handlers could block (or do anything else) if 
they felt like it. This is true for any application code though, also 
for X event handlers and such.

> I don't know what to do with:
> dbus_connection_set_wakeup_main_function(). I know it can map to
> g_main_context_wakeup() in glib, but I'm not really sure what it is
> supposed to do. I certainly can't think how it maps to lesstif.
> 
> Is it for threaded apps? The app I'm working on seems to be fine without
> it, but I thought I'd check.

This only matters for threaded apps, yep. The situation is that thread M 
contains the main loop, and thread X writes some messages to the 
outgoing queue. Thread M is blocking and needs to be kicked so it wakes 
up and does the main loop stuff to write out the message.

See
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-main-context-wakeup

Without this, if you do work from thread X that changes the status of a 
GSource, then thread M will just continue in poll() until it happens to 
get some input.

> Is the doxygen manual at 
> http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html
> 
> updated, or is it just in CVS?

it's recently updated at the moment (but always check the date on the 
bottom, sometimes it isn't ;-)

Havoc