The D-Bus specification defines D-Bus as an asynchronous message-passing system, and provides no mechanism for blocking calls at the protocol level. However libdbus and most D-Bus bindings (dbus-glib, dbus-python and QtDBus) provide a "blocking" API (dbus_do_something_and_block) that implements a "pseudo-blocking" behaviour. In this mode only the D-Bus socket is polled for new I/O and any D-Bus messages that are not the reply to the original message are put on a queue for later processing once the reply has been received.
This causes several major problems:
-
Messages can be reordered. Any message received before the reply and placed on the queue will be delivered to the client after the reply, which violates the ordering guarentee the D-Bus daemon provides.
This can cause practical problems where a signal indicating an object's destruction is delayed. The client gets a method reply "UnknownMethod" and doesn't know why until the signal is delivered with more information.
-
The client is completely unresponsive until the service replies (including the user interface). If the service you're calling into has locked up (this can happen, even in services that are designed to be purely non-blocking and asynchronous), the client will be unresponsive for 25 seconds until the call times out.
-
The client cannot parallelize calls — if a signal causes method calls to be made, a client that uses pseudo-blocking calls can't start processing the next message until those method calls return.
-
If two processes make pseudo-blocking calls on each other, a deadlock occurs.
This sort of scenario occurs with plugin architectures and shared D-Bus connections. One plugin "knows" it's a client, not a service; and another plugin, sharing the same connection, "knows" it's a service, not a client. This results in a process that is both a service and a client (and hence deadlock-prone).