Monitoring lifetimes with Python bindings

Colin Walters walters at
Fri Jul 8 05:35:16 EST 2005

On Thu, 2005-07-07 at 15:02 +0200, Ole Laursen wrote:
> Havoc Pennington <hp at> writes:
> > On Wed, 2005-07-06 at 16:45 -0400, John (J5) Palmieri wrote:
> >> @dbus.explicitly_pass_message is mainly for debugging.  Messages should
> >> not be exposed in the python bindings.  The best thing to do is for your
> >> client to send its unique name to the server when it connects to the bus
> >> and register the NameOwnerChanged signal with sender equal to the name
> >> you received.  You can also use the GetNameOwner call to get the unique
> >> name of an already running process.
> >
> > I think exposing messages would be wrong but exposing the caller of a
> > method may not be if we could figure out a good approach.
> Perhaps one possibility would be to use another decorator, e.g.
> @dbus.pass_sender, which would pass a Sender object. Sender could then
> expose get_name() to return the unique name and a disappeared() hook
> that you can connect to. The disappeared() hook would then internally
> register with the NameOwnerChanged signal and also call GetNameOwner
> to avoid the race condition.

I think the right approach is probably for the service to create a new
proxy for the client; the Python binding should have a parallel to the
GLib bindings' "destroy" signal and watch NameOwnerChanged like the GLib
bindings do.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the dbus mailing list