RFC: More fine-grained D-Bus signals

Joshua Lock josh at linux.intel.com
Mon Jul 13 03:31:23 PDT 2009

On Mon, 2009-07-13 at 10:35 +0300, Johan Hedberg wrote:
> Hi Joshua,
> On Mon, Jul 13, 2009, Joshua Lock wrote:
> > I'm wondering if we can reduce both the amount of noise on the bus and
> > the number of wake-ups if we give some of the properties, particularly
> > of the manager, their own changed signal.
> > 
> > For example, in the case of carrick, we don't care about connections or
> > profiles. And if Marcel adds his proposed Technologies property to
> > Manager then carrick won't care about devices either.
> > 
> > The attached patch adds DevicesChanged, ConnectionsChanged and
> > ProfilesChanged signals and removes the generic PropertyChanged signal
> > from the associated code paths and also when the state changes,
> If I understand correctly your worry is about waking up processes every
> time any property changes even though they might be interested only in one
> specific property, right? That shouldn't be a problem since D-Bus supports
> match rules for specific values of string-type paramters. You could e.g.
> have match rule like:
> "interface=org.moblin.connman.Manager,member=PropertyChanged,arg0=Devices"

Oh, cool. I hadn't realised this was possible. 
That's probably because this functionality is not exposed through the
dbus-glib API afaict.

> and this would only wake up the process if a PropertyChanged signal for
> the Devices property gets emitted. Would this take care of the issue
> you're seeing or was there something else (which I didn't understand) that
> makes the PropertyChanged signal undesirable?

I imagine this would be enough, of course it doesn't help anyone using
dbus-glib (myself included) so I wonder if the fine-grained signals are
still valid? Or if I just need to man up and use the D-Bus API directly.

Joshua Lock
        Intel Open Source Technology Centre

More information about the connman mailing list