PropertiesChanged signal - races...

[Michael Meeks]

On Fri, 2010-05-07 at 21:53 +0200, Thiago Macieira wrote:
> I will not implement this property in QtDBus unless there's a
> subscribe method to trigger the emission of the signal.
> Anything else is wasteful.

	I tend to agree; the accidentally inefficiencies that arrive when this
is done for every property can be somewhat staggering: a major cause of
nautilus 1.0's incredibly bad performance was, essentially this -
broadcasting great lists of icons and bookmarks to umpteen un-interested
components (by mistake) ;-)

	But more interestingly: our APIs should (in general) also try to avoid
being intrinsically racy (hard in an asynchronous world). I routinely
see code like this:

	value = dbus_call_get_property ("foo");
	foo_changed_signal_connect (my_signal_changed_cb, ...);

	where of course, there is an obvious race condition between these two
lines ( switching the order of course helps ).

	Personally, I'd love to see a:

	value = dbus_call_and_listen ("foo", foo_changed_cb);

	with a suitable async version, that combines the fetch and call,
reduces IPC, and round-trips, and makes it harder to write broken / racy
code ;-)

	Of course, perhaps that's over-kill, but IMNSHO opinion the
"enable-listening-on-properties(...)" method should return the current
values at the time the listening commenced.

	HTH,

		Michael.

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