in reply to Object Destructors and Signals

I'm having trouble getting the desctructor to work properly. Sometimes the database handle gets destroyed before my object's destructor is called and I get a cascade of errors.

Your object is a global variable or it is referenced by one. It is surviving past the end of all lexical scopes, forcing Perl to guess how to destroying what's left in memory. During global destruction, Objects can be destroyed in any order.

The direct solution would be to not use a global variable, or clean up the global yourself sooner. END{} could also help.

That said, the real reason you are having a problem is because your design fails hard. It needs to do something reliably under exceptional circumstances. Adjust your design so it fails safe, and you won't need to do anything during destruction. Perhaps transactions could be of use.

Replies are listed 'Best First'.
Re^2: Object Destructors and Signals (optimization)
by tye (Sage) on Nov 05, 2010 at 04:41 UTC
    Your object is a global variable or it is referenced by one. It is surviving past the end of all lexical scopes, forcing Perl to guess how to destroying what's left in memory. During global destruction, Objects can be destroyed in any order.

    I'd agree with all of that except for "forcing Perl to guess how to destroying what's left in memory". There is no "forcing" involved. It is more accurate to say "getting to the point where perl no longer cares in which order it destroys things".

    Global destruction is not done in an orderly fashion simply for the sake of expediency (with a name like "global destruction", what did you expect? ;). The lack of ordering is simply an optimization.

    - tye        

[reply]
      oh but it does care. There's a number of factors it considers to determine the order in which things are freed. In fact, improvements were made there for 5.14. Maybe it just doesn't care enough.
[reply]

In Section Seekers of Perl Wisdom