Re: AW: [Caml-list] Channels not closed on gc?

["Török Edwin" <edwin+ml-ocaml@etorok.net>]

On 2012-05-29 17:13, oliver wrote:
> On Tue, May 29, 2012 at 02:46:04PM +0200, Gerd Stolpmann wrote:
>> Am Dienstag, den 29.05.2012, 14:08 +0200 schrieb Goswin von Brederlow:
>>> Gerd Stolpmann <info@gerd-stolpmann.de> writes:
>>>
>>>> Am 21.05.2012 13:23:36 schrieb(en) Lauri Alanko:
>>>>> I only recently noticed that ocaml does not close open channels when  
>>>>> they are garbage collected. This is evidently intentional behavior,  
>>>>> but it was quite unexpected.
> [...]
> 
> 
> 
> [...]
>>> Lets compare this feature to boundary checks for strings and arrays. In
>>> correct code they are completly and utterly pointless since we know all
>>> our access remains within bounds. Still we do check because we know that
>>> not all code is correct.
>>>
>>> Same with channels (and Unix.file_descr). If your code is correct and
>>> you properly close them all correctly it is pointless for the GC to
>>> check and close them. But still this should be done to catch those cases
>>> where the programmer forgot about it. And this check would be a lot
>>> cheaper than boundary checks. It only checks once on destruction.
>>>
>>> And I agree that such a case should output a warning because people
>>> should not start to assume the GC will close the channel, it doesn't do
>>> so determnistically nor when the program terminates. Not closing a
>>> channel is a resource mismanagement in the code so te code should be
>>> fixed. The GC should just help to spot such cases.
>>
>> This is almost my position :-) You can output a warning in such cases
>> using Gc.finalise (which is well-documented official function, btw, so
>> nothing "internal" or so as I read here on the list). We could now only
>> argue whether this should be the default or not.
> [...]
> 
> Because the filehandles are ressources from the system,
> not just something like a value inside the users code,
> I think this should not be done implicitly.
> 
> The already mentioned side effects with Pipes are one
> reason. I remember the discussion was on this list
> many years before, and there were mentioned more reasons
> on why this should be done explicitly.
> 
> 
> So, doing it explicitly is fine.
> 
> Other languages with GC also handle this case explicitly,
> and surely not because the designers just forgot about it.
> 

To make sure that filehandles are closed properly I've lately written
with_file functions that take a filename and a function.
It then opens the file, invokes the function (in a try block), and closes the file (even if the try block threw an exception).
That way no file handles leak, and the GC is not needed to clean up.

This is in some ways similar to RAII in C++ where destructors automatically clean up resources when you leave a scope.
Maybe there should be a small library that provides these convenience functions (other resources can be handled similarly,
opendir/closedir comes to mind, but there are probably other cases where an explicit close-like functionality is needed).

Of course this can only be done if you deal with the file in a well-contained location, it would be harder to use
if you open the file in one place, and need to use it in several different places throughout your program.

Best regards,
--Edwin