[rfc] Activating Common Services
hp at redhat.com
Tue Jun 19 08:04:24 PDT 2007
Richard Hughes wrote:
> So, is HAL wrong to register itself on the bus before adding all the
> coldplug devices (other services like NM do similar things to this too),
> or should we have some sort of "activation" interface that is always
> present as soon as the service appears on the bus and also lets us shut
> a service down:
Remember not to use 'activation' in APIs ;-)
There is a StartServiceByName call already, and many can be stopped by
just taking their bus name (use REPLACE_EXISTING flag).
In general life cycle policies are service-dependent since the best
policy will vary. Some good options include:
- stop after a timeout of inactivity. next time a client
tries to use the service, allow activation to kick in
- keep track of which clients are using the service and
watch NameOwnerChanged to see when they come and go
on the bus; exit if no clients remain
- just run forever
The life cycle of particular objects offered by the service need not
match the entire service, e.g. there can be objects that are "allocated"
and "freed" by clients, as long as the service auto-frees everything if
the client disconnects.
> This would be called by the first session application that wants to
> cause the service to be activated, and also let the service know when
> it's finished. For instance bluetooth transfer software for GNOME could
> ask the bluetooth service to start, raising the refcount by one. When
> files are finished copying, the Stop method can be called, and if the
> refcount is zero then the system service can unload itself (also
> disconnecting from the hardware in the process).
> (ignoring the fact we have stale refcounts if the bluetooth file
> transfer program crashes...)
This is very key not to ignore ;-) in fact it's so critical that you are
better off just not messing with refcounts. Distributed refcounting is
both slow and unreliable.
Since the service has to monitor the client anyway to see when/if it
disconnects, it should just monitor the client - "self-refcounting" you
I think it works pretty well to have objects with explicit alloc/free
type of calls, where the free happens automatically if the client
disconnects. Then a client can help the service free things sooner, but
the service doesn't really rely on it.
I would suggest alloc/free on particular objects in the service API
rather than on the entire service, since a service API can in principle
grow arbitrarily complex. The "one bus name, one interface, one object"
pattern that leads people to ask why they are typing the same thing
three times is not the only possible pattern.
More information about the dbus