[python] destroying objects

[Robert McQueen]

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