[python] destroying objects

[John (J5) Palmieri]

Ah yes.  I must have been tired and mixed up both client and server side
cleanups.  As for removing the BusName for now you could just disconnect
and reconnect to the bus and you should lose the name though I'm not
sure if exit on disconnect is still the default in which case
disconnecting would not be the best idea :-).  Or we can just wait until
bus name removal is added to the API.

On Thu, 2005-09-22 at 15:48 +0100, Robert McQueen wrote:
> John (J5) Palmieri wrote:
> >>Or am I missing something? :)
> 
> It turns out I was... :)
> 
> > Looking at it all it seems to not be a problem.  There are a couple of
> > things that need to happen for this to be robust.  First we need to
> > implement removing filters when signals are removed.  There is already a
> > wrapper for that in the bindings but we would have to add ref-counting
> > for when two or more signal handlers are registered with similar rules
> > (you don't want to unregister one and not get signals for the other
> > because the rule has been removed from the bus).  Remember that there
> > can be more than one node for a single rule in the python match tree.
> > This is because we take the callback into account where as the bus does
> > not consider this part of the rule so it could get a slight bit tricky
> > to do the ref counting. 
> 
> ^^^ This is about unhooking match rules when a *client* object goes away.
> 
> This can be done by making the match tree keep weak references to the
> SignalMatchRules, then the __del__ of the match rule can call
> bus_remove_match. SignalMatchRules need to keep a weak reference to the
> methods they call too. Then you make the Connection.add_signal_reciever
> keep the real reference to SignalMatchRule and possibly give the client
> a handle they can use the unregister the signal later. Then we can throw
> away that reference to the SignalMatchRule on request, or when the
> client has gone out of scope (which it can do now we only hold weak
> references to it) we get a callback on the weak reference and throw our
> reference to the SignalMatchRule away,
> 
> Given that add_filter is done only once per connection for all the
> signals on a given connection, remove_filter is a red herring we can
> ignore for the moment, but probably similarly fixable with a weak
> reference too (otherwise the connection objects will never go out of
> scope either).
> 
> > Second we need to wrap dbus_connection_unregister_object_path (easy to
> > do) and use it.  If someone pulls the plug when a call is being
> > processed then the client loses.  I don't think anything more elaborate
> > is needed.
> 
> ^^^ This is about unhooking incoming message callbacks when a *service*
> object goes away.
> 
> This is not a problem at all. Provided the binding stores the references
> to a particular dbus.service.Object's message/error functions with a
> weak reference, we can make the __del__ of the Object call
> unregister_object_path when the Object's gone out of scope in the server
> process. Then we're done.
> 
> > Do you think you can hack up a patch with this.  It might take me awhile
> > to get to it.  Thanks.
> 
> I'll do the removing service Objects stuff furst, then have a look at
> removing bus names (with __del__ on the BusName object, but we need
> support for it in the bus first). At the moment my client can just shoot
> itself in the head when the service object goes away, but I'll look at
> removing match rules and filters properly in due course, otherwise the
> bindings pretty much guarantee that any objects involved will never ever
> ever ever go out of scope. :-/
> 
> Regards,
> Rob
-- 
John (J5) Palmieri <johnp at redhat.com>