[python] destroying objects

[John (J5) Palmieri]

On Wed, 2005-09-21 at 12:40 +0100, Robert McQueen wrote:
> There seems to be no support for removing objects from the bus in the
> python bindings at the moment. I had a look at hacking it in, but
> comments where unregister_object_path would be suggest it can't be done
> until remove_filter is implemented, which is tricky because (I think)
> there could be pending callbacks to the message_function_handler in the
> glib loop.
> 
> Two things... firstly it doesn't look to me like remove_filter is needed
> to implement unregister_object_path because add_filter is only ever used
> on a per-bus connection basis. Removing an object from the bus should
> just be a case of removing its signal callbacks from the match tree,
> then calling dbus_connection_unregister_object_path.
> 
> Secondly, if remove_filter does turn out to be necessary somehow, could
> you not just extend the dbus_glib_bindings to allow setting up idle
> callbacks, and hence set up a one-off idle callback to remove the filter
> after all of the pending calls have been processed?
> 
> Or am I missing something? :)

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. 

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.

Do you think you can hack up a patch with this.  It might take me awhile
to get to it.  Thanks.

-- 
John (J5) Palmieri <johnp at redhat.com>