> > 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.