On 07/17/2012 07:07 PM, Tim Bunce wrote:
> On Thu, Jul 12, 2012 at 10:38:32AM -0500, Patrick R. Michaud wrote:
>> On Thu, Jul 12, 2012 at 05:36:58PM +0300, Gabor Szabo wrote:
>> > The following script leaves and epty 'data.txt' behind.
>> > Only if I call $fh.close is the file contents saved.
>> >
>> > Is this a feature?
>> >
>> > use v6;
>> >
>> > my $fh = open 'data.txt', :w;
>> > $fh.print("hello\n");
>>
>> While Rakudo and Parrot _should_ be closing the file upon
>> program exit, it's still a good idea to close filehandles
>> explicitly. Since the GC doesn't have reference countfing,
>> it's not always the case that filehandles are automatically
>> closed as soon as the last reference is broken, thus you
>> really want to close the filehandle explicitly.
>>
>> It might be good for Rakudo and/or Parrot to have an option
>> to issue a warning whenever a open filehandle is closed due to
>> garbage collection, though.
>
> Could that be via a mechanism that could be applied to any object?
> I imagine they'll be other kinds of objects that have similar issues and
> needs.
There is a mechanism (DESTROY methods), but it relies on a parrot
feature that isn't implemented yet.
Currently the garbage collector allows some kind of callback to objects
immediately before deallocating them, but that's not enough for our
purpose, since dependent objects might have already been deallocated.
The fix is to make two phases: once the GC has determined that a set of
objects is dead, their destruction vtables are all called. After that
phase, all the objects are deallocated (except if the objects are in the
life set again, which can be determined with write barriers).
I'm CC'ing parrot-dev to ask about the current state of that project,
and to volunteer rakudo testing against any such branches.
Cheers,
Moritz
