Clarification on some bus behaviour
thiago at kde.org
Wed Sep 8 04:56:35 PDT 2010
Em Quarta-feira 08 Setembro 2010, às 12:59:56, Alban Crequy escreveu:
> I agree that they are useless.
> But if they were useful, it would be better for performances to always
> specified the interface in the 2nd and 4th match rules. Dbus-daemon
> stores the match rules in a hash table keyed by interface. Match rules
> without an interface are stored separately and needs to be checked
> against every message and it slows down the routing. See this bug for
> more benchmarks: https://bugs.freedesktop.org/show_bug.cgi?id=23117
Thanks for the pointer. I used a simple rule there because I know no one else
can be sender='org.freedesktop.DBus'.
I assumed (wrongly, apparently) that a simpler rule would be a faster match.
> > 3) Is the application allowed to assume anything about the owner of
> > the org.freedesktop.DBus name?
> > 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 unique name.
> > 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.
> I would say it does not matter if another implementation of the bus
> has an unique name like ":0" instead of "org.freedesktop.DBus" because
> the binding can still send its D-Bus messages to the well-known name
> "org.freedesktop.DBus" directly. The spec says:
> "This method call [methods on org.freedesktop.DBus] should be sent to
The outgoing message is not the issue.
The problem is the incoming one. On incoming messages, the sender is always
the unique connection. So I need to know what sender to expect in messages
that come from the bus itself.
The way QtDBus works is that, when you connect a signal with sender="foo", it
will do three things:
1) add a match rule with sender='foo'
2) start listening for the NameOwnerChanged signal with arg0='foo'
3) call GetNameOwner('foo')
That's why you saw in my trace that something happened in-between add_match
for NameAcquired and NameLost.
Internally, the binding keeps an associative map between all names that it's
listening to signals from and their current owners. When a signal message
comes from a particular owner, it needs to check whether that connection
currently owns any of the watched names.
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