PropertiesChanged signal - races...
michael.meeks at novell.com
Mon May 10 02:47:47 PDT 2010
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
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.
michael.meeks at novell.com <><, Pseudo Engineer, itinerant idiot
More information about the dbus