Front page | perl.perl6.internals |
Postings from April 2005
At 7:24 PM +0200 4/28/05, Robin Redeker wrote:
>I just wanted to correct my small example:
>
>On Thu, Apr 28, 2005 at 05:00:53PM +0200, Robin Redeker wrote:
>> > Robin Redeker writes:
>> And with explicit resource handling (without timely destruction) it may be:
>>
>> {
>> my $s = new CoolClass;
>> ...
>> destroy $s;
>> }
>
>This should actually be, to prevent the resource from leaking:
>
> {
> my $s = new CoolClass;
> eval {
> ... do stuff that may throws ...
> };
> destroy $s;
> }
That's not necessary to prevent the resource from leaking. It's only
necessary if you want to unconditionally destroy the object when
control is leaving that block for the first time. You probably don't
want to, since that means any outstanding references will now refer
to a dead object.
If you don't have the destroy, and don't tag the object as needing
expedited cleanup, then the finalizer *will* still be called. You
just don't have any control over when its called.
> > Not that big difference. And this is what we have with
> > refcounting/timely destruction:
>>
>> {
>> my $s = new CoolClass;
>> ...
>> }
>>
>
>The latter example will destruct nicely if something throws.
Regardless of GC method, yes. The only question is when.
It's *really* important to note that I explained how parrot does GC
-- that wasn't opening a descussion on redesigning the feature.
Parrot doesn't have, and isn't going to have, a refcounting GC
system. That's just not an option.
Parrot's got a tracing GC system triggered on demand by failure to
allocate resources, explicitly by user code, or at regular intervals.
Switching to a different tracing system than what's in now is doable.
Switching away from a tracing system *isn't*. That'd require changing
the entire source base, and just isn't feasible.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thread Previous
|
Thread Next