Monitoring lifetimes with Python bindings
walters at verbum.org
Fri Jul 8 05:35:16 EST 2005
On Thu, 2005-07-07 at 15:02 +0200, Ole Laursen wrote:
> Havoc Pennington <hp at redhat.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050707/4bb5341c/attachment.pgp
More information about the dbus