PropertiesChanged signal - races...

Michael Meeks michael.meeks at
Tue May 11 02:21:14 PDT 2010

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.


> 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 :-)



 michael.meeks at  <><, Pseudo Engineer, itinerant idiot

More information about the dbus mailing list