PropertiesChanged signal - races...

David Zeuthen zeuthen at
Tue May 11 04:01:53 PDT 2010


On Tue, May 11, 2010 at 5:39 AM, Thiago Macieira <thiago at> wrote:
> Here's an idea:
> org.freedesktop.DBus.Properties:
> GetAndSubscribe(in string inteface_name, in string property_name, out variant
> value, out boolean subscribed)

(Would probably want a GetAll() to avoid message header overhead)

> That triggers fetching of a property for the first time and also subscribing
> for updates. The boolean return indicates whether the subscription is
> successful or not (some properties may not be watchable).
> The new property value would be carried by the PropertyChanged signal. But
> only watched properties would be ever notified.
> There would have to be a counterpart for unsubscribing. And the big issue is
> that bindings need to do the proper watching for services disappearing in
> order to decrease the ref-count of watched properties. It would be nice if the
> bus did that for us.

OK, but assuming with had this optimization that the bus would tell
when AddMatch() is called (for any signal), I think what are you
proposing isn't functionally different from just this

 - the proposed PropertiesChanged(a{sv} changed_props) signal

 - two new annotations
   - <annotation name="org.freedesktop.DBus.Properties.EmitsChanged"
   - <annotation

It strikes me it's actually functionally equivalent, isn't it?

(Except that we won't get any optimization until we add the "tell me
when people subscribe to a signal" feature to the the message bus.)


More information about the dbus mailing list