> > I beleive there could be some sort of optimization when
> some things are done
> > at first invoke, and never done if subroutine never called...
> > But this is irrelevant in our case, I beleive.
>
> I don't find it irrelevant since it's this that makes Tcl drop
> ownership of the perl CV.
I meant relying on implementation/optimization details isn't a way to go.
Not "irrelevant" but rather "inapplicable"
> > > Perhaps there is no hope for getting rid of %anon_refs
> and the current
> > > CV leakage.
I think I got it.
Actually when I tried approach in pure-perl test code, I seem to reach the
needed behaviour.
First, I tried simple code borrowed from your example. I was surprised to
know that subroutine is different each loop iteration, and this helped me.
my $a = 1;
for (0..3) {
$s = sub { $a };
$srefs{"$s"}++;
}
print STDERR '[[',(join '++',sort keys %srefs),']]';
------------------------------
Then following code has all desired behaviour within subs, as they seem to
properly deleted at their time:
my %srefs; # srefs = "stringinfied references"
package better_sub;
sub DESTROY {
my $s = shift;
delete $srefs{"$s"};
print STDERR "I ($s) did my cleanup and go away\n";
}
package main;
my $a = 1;
for (0..3) {
$s = sub { $a };
bless $s, better_sub;
$t = $s if $_==2;
$srefs{"$s"}++;
}
#check if they are callable;
print STDERR '{{',$s->(),$s->(),$t->(),$t->(),"}}\n";
undef $s;
undef $t;
print STDERR '[[',(join '++',sort keys %srefs),']]';
----------------------------------------------------------------------
When I played with this (still simple) code, I came into conclusion that it
does what required. (otherwise please let me know)
I beleive you do not need to go to XS level to implement proper
de-allocation of subroutines.
Or, they could be pure-perl at first, and then go to XS for efficiency
later.
I can try to go this way to check the concept, but most likely this will be
at next weekend, so if you can try this approach sooner, please do so.
> > - keep Tcl-interpreter-wise %anon_refs, and delete all
> references from it
> > when interpreter is destroyed.
>
> I don't see much point in this as the Tcl interpreter will usually
> live as long as the app lives.
indeed.
Vadim.
