Front page | perl.perl5.porters |
Postings from August 2003
According to Simon Cozens:
> Yitzchak Scott-Thoennes:
> > > > my $y;
> > > > { my $x = bless sub { $y }, 'X'; }
> > > > sub X::DESTROY { print "DESTROYED\n" }
>
> My initial reaction is that calling a destructor on a sub that happens
> to be a closure and not on one that doesn't is not just an unexpected
> special case, but it's surely a bug. Why (and I ask this honestly, not
> rhetorically) is it supposed to be so hard to fix?
Because every value of
$a = sub { print "hi" }
is the same CV. Printing $a will confirm this. The original owner of
the CV is the OP tree for the enclosing subroutine (or eval). Until
the owning OP tree goes away, the CV's refcount cannot fall to zero.
It's very much like
sub hi { print "hi" }
$a = \&hi;
The only difference (WRT GC) is that in the \&hi case the original
owner is the symbol table, which is visible and can be manipulated
from Perl.
In contrast, every value of
my $foo;
$b = sub { print $foo }
is a _new_ CV; printing $a will confirm this. Therefore there is no
'original' owner of each new CV; when $b (in this case) lets go, the
new CV can be GC'd (and thus DESTROYed). (BTW, there is a parent CV
from which all the closure CVs is cloned. This CV is totally hidden
from user code. It belongs to the OP tree.)
--
Chip Salzenberg - a.k.a. - <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Thread Previous
|
Thread Next