signals and proxies for names

[Havoc Pennington]

On Tue, 2005-06-28 at 02:36 -0400, Colin Walters wrote:
> 
> I realized just as I was about to send that even this might not be
> sufficient in that there is potentially a race (I think).  We call
> GetNameOwner when a proxy is first created with
> dbus_g_proxy_new_for_name, and then keep track of owner changes with
> NameOwnerChanged.  But if we have a stale NameOwnerChanged signal queued
> in the buffer when we create the proxy, then we'll process
> NameOwnerChanged, but it's now invalid.  Probably need to keep track of
> the message serials and ignore NameOwnerChanged if its serial is before
> the reply from GetNameOwner.
> 

Right. If you do this, we need to update the spec to note that serials
must be ascending; I'm not sure this is in there right now.

I'd use bitfields here for space:

  gboolean for_owner;         /**< Whether or not this proxy is for a
name owner */
+  gboolean associated;        /**< Whether or not this proxy is
associated (for name proxies) */


Higher-level comment is that much of the point of new_for_name() over
new_for_name_owner() was to avoid blocking when creating the proxy.
There's this potentially-wacky but existent nonetheless overall theme
I've had for dbus, which is to think about starting up a normal desktop
app and avoiding as many round trips as possible as the app is setting
up.

Anyhow, in this spirit I think it would be important to send the
GetNameOwner and then just treat the reply to it like a NameOwnerChanged
processed async. This fixes the race condition incidentally also.

The other performance issue that comes up in this patch is that we'll be
waking up the whole desktop for every NameOwnerChanged - which probably
brings us back to Anders' detail patch. Here though there's some case
for doing matching based on the args of the signal (either old or new
name). Increasingly something like the Anders patch seems important for
1.0.

Havoc