views:

95

answers:

1

I am starting to use D-Bus as the IPC mechanism for a new project in Linux/KDE. And I've discovered that the documentation does not really address concurrency at all. How are D-Bus services expected to deal with multiple concurrent calls coming in from different clients? What's the threading model? Can a service assume that it is single-threaded and D-Bus will queue up requests on its own?

+3  A: 

As a protocol, D-Bus doesn't address threading.

D-Bus connections receive message serially. At the protocol level, replies to message are asynchronous: i.e. the sender doesn't have to wait for replies before sending more messages.

While in principle a D-Bus implementation could dispatch messages to service implementations concurrently, I don't know of any that do this.

Typically, a D-Bus implementation (or "binding", if you will) allows the service to decide for each method (or even for each method call) whether to respond to incoming method calls synchronously or asynchronously. The details of this are up to the particular implementation you're using.

If you're responding to method calls asynchronously, your service implementation is responsible for making sure that any state is kept consistent while multiple responses are pending. If you always respond synchronously, then you know you're only dealing with one method call at a time.

daf
Thanks. This is consistent with what I saw in Kubuntu using the Qt binding. If I set a breakpoint in my remote service method (slot) and then called it from two clients, the second client was completely blocked until my code had finished processing the first message. But I wasn't sure if I could rely on this.
Rob H