PropertiesChanged signal - races...

[Thiago Macieira]

Em Terça-feira 11. Maio 2010, às 11.21.14, Michael Meeks escreveu:
> Hi David,
> 
> On Mon, 2010-05-10 at 14:24 -0400, David Zeuthen wrote:
> > Right, the whole point of standardizing on a PropertiesChanged signal
> > on the org.fd.DBus.Properties interface is exactly that
> 
> 	Sure ! I love it :-)
> 
> > : 1. to avoid people making the same mistakes over and over again;
> > 
> > and 2. to avoid overhead (e.g. each client calling Get() or GetAll()
> > again)... because without a standardized signal it's hard to add
> > proper support at the library/toolkit level.
> 
> 	Naturally.
> 
> > To get anywhere, though, it's important to stress that you have to
> > start somewhere. The addition of this signal to the spec is the first
> > step in that direction...
> 
> 	Yep - I was just commenting on Thiago's good advice (or
> pre-requisite ?) of having some sort of in-producer-process filtering of
> the notifications; and, of course, if you have that api - it should be
> trivial to ensure that it is designed to avoid the race I outline (and
> have had to fix several times in other people's code) ;-)
> 
> 	The idea of filtering in the bus itself misses the point that you then
> still do a load of notifications, and that you also have to do a
> round-trip to the property-holding process anyway -after- setting up the
> listener, to get the current state of the property: otherwise you have a
> race :-)

Here's an idea:

org.freedesktop.DBus.Properties:

GetAndSubscribe(in string inteface_name, in string property_name, out variant 
value, out boolean subscribed)

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.

-- 
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
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100511/1da1a271/attachment.pgp>