Question related to NameOwnerChanged signal

[Alban Crequy]

Le Wed, 14 Oct 2009 00:58:28 +0530,
Shakti Ashirvad <shakti.ashirvad at gmail.com> a écrit :

> I have been using both native dbus and dbus-glib for quite sometime
> for an embedded device. All applications in our domain is linked to
> libDbus. Recently while working on a performance enhancement and
> overall health diagnostics, I discovered that everytime a process is
> spawn, DBUS daemon broadcasts few signals, which are making every
> process in the system do context switch at least once.

Yes, the semantic of NameOwnerChanged is in the spec:
NameOwnerChanged (STRING name, STRING old_owner, STRING new_owner)
http://dbus.freedesktop.org/doc/dbus-specification.html

> As a result the launch of the application is significantly affected.
<skip>
> Could someone help me here to understand why these signals are
> broadcast and needed by all the apps. Is there any way I can match
> rule and send to particular processes. And the match rule being the
> PIDs or anything that makes sense.

You can use match rules on 'arg0', for example something like:

type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',sender='org.freedesktop.DBus',arg0='org.freedesktop.Telepathy.ConnectionManager.gabble'

The process using that match rule will wake-up only if the signal
NameOwnerChanged has the first parameter equals to what you want (see
the spec for more details).


If your process still receive NameOwnerChanged, it is probably because
there is other match rules for your process, but it may be difficult to
find where exactly they are added. You can use the patch+script attached
to the following bug in order to list all the match rules: (for
debugging only, the quality of my patch is not good enough yet imho,
but any review and help is welcome)

[PATCH] GetConnectionMatchRules for application debugging
https://bugs.freedesktop.org/show_bug.cgi?id=24307

You may find broad match rule (i.e. without a 'member=' criteria) on
the bus driver:

type='signal',interface='org.freedesktop.DBus',path='/org/freedesktop/DBus',sender='org.freedesktop.DBus'

This rule may be generated by DBusGProxy on the bus driver, i.e. if you
do something like this in your code:
  dbus_g_proxy_new_for_name (connection,
    DBUS_SERVICE_DBUS,
    DBUS_PATH_DBUS,
    DBUS_INTERFACE_DBUS);

With the current dbus-glib, a broad match rule on the bus driver will
exist as long as your proxy is living. The patch in the following bug
fixes that:

DBusGProxy should be able to filter signals
https://bugs.freedesktop.org/show_bug.cgi?id=23846

I am looking for a reviewer for my patch. I am running it every
day on my GNOME desktop and it works for me :-)

Regards,
Alban Crequy