Clarification on some bus behaviour
thiago at kde.org
Wed Sep 8 02:56:13 PDT 2010
While trying to profile the QtDBus binding on an ARM board (yes, I have to deal
with those too), I found out that the binding spends 18 ms during the
connection startup doing the following:
dbus_bus_add_match("destination='insert my own unique connection here'");
blocking call to GetNameOwner("org.freedesktop.DBus")
Now, the interesting thing is that, with the reference implementation of the
dbus-daemon, I *know* that all of the above are useless. These calls are there
because my reading of the spec tells me that they are necessary.
So, I have three questions that need clarification:
1) Is the application allowed to assume that the bus will send all messages
that have this connection as a destination, without having to add a match rule
for it? In other words, can I drop that first add_match above?
I would think that the answer here is Yes. This rule should be implicit.
There's also a race condition here, if this weren't the case: another process
could send my application a message at the moment that my unique name appeared
on the bus, but before I had a chance to add the rule. If the rule weren't
present, the message would not be delivered.
Another aspect is that the caller has the guarantee from the bus that any
directed message (anything but a signal) will either:
a) be delivered to exactly one (non-eavesdropping) destination
b) be returned with org.freedesktop.DBus.Error.ServiceUnknown
If a connection is allowed to exist without the rule for its destination,
directed messages could disappear into the ether...
2) Is the application allowed to assume that the bus will always send the
NameAcquired and NameLost signals without having to add a match rule for it?
In other words, can I drop the second and fourth add_match calls above?
I would think that the answer here is also Yes.
These two signals are special in that they are the only kinds of directed
signals. They are delivered exclusively to the connection that acquired or
lost a name. By the rule above that directed messages are always delivered to
their destination, I would conclude that these two signals are always
3) Is the application allowed to assume anything about the owner of the
I think the answer here is No.
The reference dbus-daemon has the owner of org.freedesktop.DBus as also
org.freedesktop.DBus, even though that's not a unique connection name. I could
think of a different implementation using something like :0 or :1.0 as the
Therefore, I'd say that a binding must not assume anything about the actual
owner of the bus service. That GetNameOwner call of mine must still be there.
However, it should be ok to assume that the name never changes owners, so the
third add_match of mine can be skipped.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus