Raw libdbus dispatching
hp at redhat.com
Tue Oct 24 14:04:35 PDT 2006
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.
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
> 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 ;-)
More information about the dbus