D-Bus object callbacks

Havoc Pennington hp at pobox.com
Thu Sep 30 19:37:38 PDT 2010


On Thu, Sep 30, 2010 at 4:44 PM, Matteo Vescovi
<matteo.vescovi at yahoo.co.uk> wrote:
> Can this be accomplished?
> Can you provide any pointers how this can be done? In particular, how
> can I have the client process execute its own mainline and still have
> D-Bus objects servicing remote invocations?

The easiest and least-weird-unexpected-results way to do this is to
make one of the two calls asynchronous rather than blocking.

If you want to block, you have two approaches. One is to use threads
(which runs into various tricky problems with libdbus, and probably
doesn't work at all with dbus-glib). The other is to run a recursive
main loop to wait for the reply (which produces a re-entrancy problem
that will probably crash or confuse your app occasionally). Neither of
these things is a great plan so just making the calls asynchronous is
the usual approach.

Asynchronous calls means
dbus_connection_send_with_reply() or dbus_connection_send() basically,
without using dbus_connection_send_with_reply_and_block() or
Normally you use dbus_pending_call_set_notify() to learn about
replies. Obviously you'd ideally use a high-level binding that wraps
all the boilerplate involved here, or at least do your own convenience
functions. If your method call doesn't have a reply, then it's pretty
easy and simple since you can use dbus_connection_send() and ignore
all the pending reply stuff (caveat: you won't get errors back this

There is a new "gdbus" in the latest GLib that is a lot nicer than
dbus-glib or libdbus btw, API-wise.

If rolling your own, here are some notes:
Or an example of a hand-rolled convenience API:

Trying to use threads has a couple issues,
1) you really have to define some sane model for it (which thread does
what, what the rules are) and this is actually Hard and libdbus is
completely agnostic/unhelpful/policy-free
2) there seem to be libdbus bugs; libdbus tries to work right with
threads but things are too undefined/untested and most people seem to
encounter issues, not helped by problem 1).


More information about the dbus mailing list