Re: Problems with signals and object destruction



On Fri, 2007-04-20 at 13:48 +1000, Daniel Kasak wrote:
muppet wrote:

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.

Cool.


The situations you want to watch out for are:

- Any form of circular reference.  Avoid keeping references to yourself.

Doh! In Gtk2::Ex::Datasheet::DBI I'm creating circular references so 
that TreeViewColumns have access to the definition used to set them up. 
I was wondering if this would create problems ... certainly EPIC ( 
Eclipse Perl debugger ) doesn't like it. I'll come up with a less dodgy 
way of packing info into TreeViewColumns.

[snip]

Anyway, I'll look into getting rid of those circular references.

You could just weaken the reference, using weaken from Scalar::Util.
That should keep your objects from leaking, without major surgery on you
code.

./borup




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]