test suite failure - more detail ...

Olivier Andrieu oliv__a at users.sourceforge.net
Thu Apr 22 19:57:16 EST 2004


 Havoc Pennington [Wed, 21 Apr 2004]:
 > Another possible API is:
 >  DBusServiceState dbus_gproxy_get_service_state (DBusGProxy*)
 >  typedef enum { DBUS_SERVICE_STATE_OWNED,
 > DBUS_SERVICE_STATE_NONEXISTENT, DBUS_SERVICE_STATE_UNKNOWN }
 > DBusServiceState;
 > 
 > with signal "(* state_changed) (DBusGProxy*, DBusServiceState old_state,
 > DBusServiceState new_state);"

Yeah, that's what I'm thinking about.

 > But are apps testing for whether the proxy is ready to emit signals, or
 > are they testing for whether the service exists. How does this relate to
 > dbus_bus_service_exists() for example?

Well, both. The idea is that the proxy manager is keeping track of
services ownership (it has to do so to be able to route signals).
This is just a way of letting the application access this information.
Right now, the proxy manager API is not public ; I guess another way
is to make part of that API public.

dbus_bus_service_exists() involves a round-trip to the bus. The proxy
manager might already know about the service and thus could give
answer right away.

 > Why would you check for proxy readiness, to avoid race conditions?
 > If so how would you block until the proxy is ready, or how would
 > you sync with another thread or process?

Ermm, no I wasn't thinking of that kind of things. 

-- 
   Olivier



More information about the dbus mailing list