Re: Problems with signals and object destruction

[muppet <scott asofyet org>]

On Apr 19, 2007, at 8:37 PM, Daniel Kasak wrote:


> Anyway, I'm going to *great* lengths to track all the signals I  
> connect,
> and disconnect them when closing down ( honest ). And yet object
> destruction still doesn't work.

This sort of gymnastics should not be necessary.  GObject will  
destroy all of its signal handlers in the base GObject::dispose()  
method (part of the destruction process), and Glib::Object connects  
those with closures so that we get proper destruction notification  
for cleaning up the callback subroutine and user data references.   
With that, and reference counting everywhere, everything should Just  
Work.

The situations you want to watch out for are:

- Any form of circular reference.  Avoid keeping references to yourself.
- Take care with closures, and they can hide references to objects  
and create reference cycles.
- NEVER override DESTROY on a Glib::Object, or you will break object  
destruction.  (This is documented in the Glib::Object::Subclass  
manpage.)

For things that are necessary reference cycles, your basic hammer for  
that nail is the GtkObject's "destroy" signal, where you can delete  
things that don't clean up nicely.  But, for the most part, since the  
bindings take care to make sure that all perl objects are held in  
such a way that references are released at the right time, this is  
rarely a problem.  (In fact, although i've had to deal with this  
before, i can't clearly remember the situations.)



> Is there a way I can list all signals connected to an object?

From looking at the gobject source:  You can:

- list the signals of a type or instance (g_signal_list_ids(),  
Glib::Type::list_signals())
- ask whether a particular instance has any handlers connected to a  
particular signal (g_signal_has_handler_pending(), not bound to perl)
- ask for the first handler connected to a signal on an instance  
(g_signal_handler_find(), not bound to perl, mostly because of heavy  
magic requirement to implement)
- block, unblock, and disconnect a given handler or handlers that  
match in name, callback, and data (several functions, look for  
"by_func" in Glib::Object)

but as far as i can tell, there is no way to list all of the handlers  
connected to a signal.  And, really, you shouldn't need to.



> Am I  correct in assuming that it's my inability to cleanly destroy  
> stuff
> that's leading to crashes? Or maybe I'm exposing a Windows-only bug?

I'm not convinced it's a cleanup issue, since a) it's supposed to  
Just Work, and, b) as you say, it manifests only on windows.

Now, can you *verify* that this stuff doesn't happen on windows?  Try  
running your app under valgrind on linux, and watch for any bad  
accesses.  Linux is often a little bit more forgiving about such  
things than windows.



--
I hate to break it to you, but magic data pixies don't exist.
  -- Simon Cozens