DBus Un-activation

[Havoc Pennington]

Hi,

On Mon, Sep 8, 2008 at 3:12 PM, Colin Walters <walters at verbum.org> wrote:
> I believe the reason this is hard is because if your server exits, it
> will create a race condition where clients trying to talk to it just
> before it chooses to exit can see their messages dropped.

This should not be a race if the server releases its bus name and
processes the entire incoming message queue before it exits. The only
race is if the server gets a message and ignores it, by dumping part
of the queue. But if the server releases its name, a new server
instance can start from that point forward; so the old server just has
to finish up, and allow the new server to handle any new clients.

> Anyways for now I would concentrate on making your service lightweight
> if you can.  The refcount approach might be "good enough" for now too.

The refcount approach is broken because the client might not unref.
Instead, use the "client registration" pattern:
* server tracks the unique bus name of all clients, and watches for
those bus names leaving the bus
* if all client bus names leave the bus, the server knows it can exit,
typically after an inactivity timeout
This handles a client crashing, for example.

dbus bindings should support this pattern, but none of them do yet. In
the meantime implementing it involves some tedium.

Havoc