DBus Un-activation

David Boucher boudav at gmail.com
Wed Sep 10 08:45:21 PDT 2008


Le Mon, 8 Sep 2008 16:25:17 -0400,
"Havoc Pennington" <hp at pobox.com> a écrit :

> 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

I've tried to follow your advices. So, this my new solution:

When a client is started, it is connected to the signal
org.freedesktop.dbus.NameAcquired

Once the name is acquired, the client sends its name to the server via a
method RegisterClient(name)

On the server side, all the clients names are put in a GSList.

The server is also connected to the signal
org.freedesktop.dbus.NameOwnerChanged, so it is easy each time a client
exits, to remove it from the list of clients.

Then, when the list is empty, the kernel can exit.

Is there an easier way to get the bus name of the client or can I be
happy with this solution ?

Thanks !
David.


More information about the dbus mailing list