When you say global, do you mean a lexical with package or file-level scope or do you mean a true global accessible through the symbol table?

If the former, as I suspect, then Perl's reference counting GC may be tripping you up. In that case, every subroutine that refers to a lexical in an outer scope is a closure and increases the refcount of the lexical. At shutdown time, when Perl GCs the subroutines themselves, that reference count decreases.

It sounds to me like you need a separate finalize() method to call explicitly, rather than waiting for DESTROY(). That way, you can avoid the rather messy and unspecified order of destruction errors I think you're having.

Perl's global destruction is a race for the exit. Who knows what order things will happen?

If oyasuminasai-san isn't using a lexical, that would be the first thing to try. Lexicals should always go away before globals.

I had similar troubles with global destruction. I found this thread (Object reference disappearing during global destruction) and I thought I understood what was my error: to rely on the reference-count mechanism even during global destruction. Seeing the topic popping out again, I decided to do some experimentations in order to acquire a (?better) grasp on the subject. Here's the code:

use strict;
use warnings;

package Bar;
use Devel::Peek 'Dump';

sub new { bless [], shift }

sub bar { print "Hi, I'm a bar instance\n\n" }

sub dump 
{
    print "This is my ID card:\n";
    Dump( shift )
}

package Foo;

sub new 
{
    my $bar = Bar->new();

    bless { bar => $bar }, shift;
}

sub DESTROY 
{
    my $self = shift;
    $self->{ bar }->bar();
    $self->{ bar }->dump();
}

package main;

my $f = Foo->new();
[download]

My expectation was to see a message like Can't call method "bar" on an undefined value with unpredictable frequence. I run the script several times, without warnings. Since this is a semidecidible issue, and I don't have all that time :), I ask if my understanding is correct, and further explanations if appropriate. Thank you.

At the end of the program, I'd expect $f to go out of scope first, calling its DESTROY. Since it contains a reference to a Bar, the contained object should still exist, so things are okay.

If $f were global or if it had more than one reference, things might be stickier.

It is a lexical with file level scope. And I suspected that the closures were incrementing the reference count... that's why I tried removing those closures to see what happenned. I guess I was trying to avoid forcing the user to remember to call the finalize method - the people that will use my library are not what you would call expert Perl programmers and I wanted to make it so that changes were not committed unless they knew what they were doing... Thank you for your help - I will most likely just throw in the finalize and perldoc it that way.

oyasuminasai

"Or are you using rollback to enforce commits for the callers in their logic?" -> Yes.

Thanks for the tip, I took a look at it, but one of the primary goals was to keep the library lightweight and targetted towards the enterprise's concerns. Alzabo looks very complete, but also very large not centered on this company's uses for it.

By your reasoning it sounds as though you wouldn't agree to people writing and XML parser when there is already XML::Xerces and the like. Sometimes you need something designed in tandem with your specific problems in mind. But I don't want to sound ungrateful, I appreciate the tip.

oyasuminasai

Speaking as a user of Xerces (in Java) and now a handful of other parsers on perl, in general this stuff is best to hand off to someone else unless you're willing to go and produce a complete implementation. Eventually you look at long-term maintenance or feature creep and eventually you just end up reimplementing one of the already complete packages.

To make a generalization anyway.