Shevek writes:
> On Fri, 2005-01-14 at 16:56 -0700, Luke Palmer wrote:
>
> > > I thought C++ only guaranteed destruction (on return or exception) for
> > > objects which were directly on the stack.
> >
> > That's true, you have to explicitly delete most memory. I was actually
> > referring to the template refcounting classes that I use all the time:
> >
> > void foo() {
> > ref<Image> image = new Image("somefile.jpg");
> > image->draw();
> >
> > // image will be cleaned up automatically
> > }
> >
> > Here, C++ manages only to refcount objects (or rather, pointers) that
> > are declared using ref<> instead of *. In a dynamically typed VM this
> > isn't possible.
>
> Yeah, but the ref<> object is directly on the stack, and destruction of
> that, and thus decrement of the refcount, is guaranteed. Um.
Yes, I understand that. So, moving on...
> 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. :-)
Here it is again:
my %data;
sub a {
open my $fh, "> somefile";
$data{fh} = $fh;
}
sub b {
%data = ();
}
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
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.
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.
> 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.
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.
No matter how we slice it, it would royally suck to add a sweep at the
end of every lexical scope.
Luke
