PropertiesChanged signal - races...

[David Zeuthen]

Hey Michael,

On Mon, May 10, 2010 at 5:47 AM, Michael Meeks <michael.meeks at novell.com> wrote:
>        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 ;-)

Right, the whole point of standardizing on a PropertiesChanged signal
on the org.fd.DBus.Properties interface is exactly that: 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.

(FWIW, in GLib, the library code taking advantage of such a signal is
in the GDBusProxy class and the g_bus_watch_proxy() routine. See
gdbus-example-watch-proxy.c for an example of how these are used.)

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...

     David