In which Tigger maintains that code relying on timely destruction in
perl5 is buggy [and relatively rare], and agrees wholeheartedly with
Rabbit on almost everything else.
On Fri, 2005-01-14 at 17:52 -0700, Luke Palmer wrote:
> Shevek writes:
> > The example you described destroyed a ref within a sub, and then assumed
> > that the object refed would be destroyed at scope exit.
>
> I'm assuming you're referring to my Perl example, which you tactfully
> omitted in order to lose the casual reader. Very cunning. :-)
My mistake, I was too heavy with [del]. I meant to put it back in.
> Here it is again:
>
> my %data;
> sub a {
> open my $fh, "> somefile";
> $data{fh} = $fh;
> }
> sub b {
> %data = ();
# $fh is destroyed here, not at scope exit
foo();
bar();
# not here.
> }
> a();
> # ...
> b();
>
> And what I mean is that most approximate solutions won't destroy $fh in
> time. One example of such a proposal is keeping tabs on objects in the
Timely destruction in C++ (I think the only language we have mentioned
which _officially_ implements it) only happens at scope exit. "Timely
destruction" in Perl5 happens (probably) kind of when the ref goes away,
although I don't think even that is guaranteed, my memory of temporaries
and targets is too fuzzy.
> current scope which need timely destruction and then do a sweep whenever
> we lose a reference to one. Another is using generational schemes.
> Generational schemes are good for finding *enough* dead objects quickly
> when we run out of memory, but they're not good for finding whether a
> particular object is dead.
But they may be adequate in a pinch for handling many simple cases of
timely destruction. However we are likely to dig the same hole as perl5
where programmers rely on the behaviour [see bottom].
> However, Perl 5, since it uses refcounting everywhere, has no problem
> with this. Parrot has decided not to use refcounting at all (a decision
> that I think I agree with), and so we have this problem.
>
> > This is incorrect: the object refed should be destroyed when the ref is
> > destroyed in a general refcounting GC system.
>
> And I don't understand what you mean here.
The example above demonstrates.
> > Anyway, this led me to the (useful?) thought that you could delink the
> > concept of timely GC and destruction at scope exit by registering
> > atexit() or atleave() code on a scope (like finally{}) which explicitly
> > undef'd registered PMCs. That way you would be able to guarantee
> > destruction even if the PMC was still ref'd, which is probably more use
> > for things like critical section locks than just relying on a
> > side-effect of the GC, and is certainly easier to implement since it's
> > just a flag on the lexical in the pad.
>
> Precisely! But if we have to support this area of Perl 5 (I'm not
> certain that we do yet), we have to implement its semantics
> backward-compatibly. The programmer of Perl 5 relied on the side
> effects because they worked then. So we're not allowed to break them.
I maintain that relying on those semantics is a clear violation of the
documentation, as explicitly stated somewhere I can't immediately find,
but someone else must be able to find the passage. Such code may be
considered broken. I also suspect it's not a hugely common case.
> And because of Perl 6's many lexical scope hooks, I hope that we can get
> rid of any timely destruction policy, to encourage the use of lexical
> hooks instead of destruction rules.
Yes. Lexical hooks good.
> No matter how we slice it, it would royally suck to add a sweep at the
> end of every lexical scope.
I wouldn't worry too much about a last-generation sweep at that point,
especially if we know which zones are in scope (as opposed to extent) at
that time. However, I doubt anyone is going to implement this.
S.
