Front page | perl.perl5.porters |
Postings from December 2004
>
> > Subject: [perl #32714] Objects destroyed in the wrong order during global
> destruction
>
> I thought order of destruction in perl in general was undefined? At least
> Perltoot seems to agree with me:
>
> "Perl's notion of the right time to call a destructor is not well-defined
> currently, which is why your destructors should not rely on when they are
> called."
That is talking about something else that is irrelevant in this case.
That paragraph refers to this situation;
{ my $obj = Class->new;
...
}
B;
The question here is whether Class::DESTROY is called immediately at
the end of the block, before B is executed. The paragraph you quote
is warning us that that might not be the case.
However, the problem I am reporting is a different situation. Here, a
piece of data is destroyed prematurely, while there is still a
reference to it. That is not the same thing at all; Perl *does*
guarantee that it will not destroy an object that is reachable from an
executing program.
In my example, Perl's premature execution of the inner object while
there is still a reference to it from the outer object is a bug, and
one that could easily lead to a core dump or other bad behavior.
> Im wondering why Perl doesn't have a counter whose value is incremented and
> assigned to each blessed object when they are blessed.
It maintains a count of the number of references to each object; this
count is intended to prevent exactly the behavior I am reporting.
That it does not, in this case, indicates that there is a bug.