PropertiesChanged signal - races...

[Michael Meeks]

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

	HTH,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot