Question related to NameOwnerChanged signal

[Shakti Ashirvad]

Hi Guyz,

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.

As a result the launch of the application is significantly affected. The signals are,

Signal Received (null) (null), Sender : org.freedesktop.DBus
Signal Received (null) (null), Sender : org.freedesktop.DBus
Signal Received (null) (null), Sender : org.freedesktop.DBus
Signal Received (null) (null), Sender : org.freedesktop.DBus
Signal Received org.freedesktop.DBus NameOwnerChanged, Sender : org.freedesktop.DBus
Signal Received org.freedesktop.DBus NameOwnerChanged, Sender : org.freedesktop.DBus

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.

Thanks,
Shakti

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Colin Walters]

On Tue, Oct 13, 2009 at 7:28 PM, Shakti Ashirvad
<shakti.ashirvad@...> wrote:
> Hi Guyz,
>
> 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.

This was significantly improved this year with this commit:

commit dfef72c61c050e7f57e1d2eb601701e0a27827cc
Author: Colin Walters <walters@...>
Date:   Thu Feb 5 11:17:15 2009 -0500

    Bug 14183 - Listen to NameOwnerChanged using arg0 matching

    This is more efficient - we avoid waking up every dbus-glib using process
    when a process joins or leaves the bus.
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Alban Crequy-4]

Le Wed, 14 Oct 2009 00:58:28 +0530,
Shakti Ashirvad <shakti.ashirvad@...> 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
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus