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

[Goswin von Brederlow <goswin-v-b@web.de>]

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.
>> 
>> To be clear, I do think it's bad style to rely on GC for releasing OS  
>> resources, but that doesn't explain why GC shouldn't do this if the  
>> programmer has failed to explicitly close the channel. And if the  
>> intention were to _enforce_ good style, the channel finaliser would  
>> spout out an error or warning upon detecting that the channel hasn't  
>> yet been closed, instead of just silently leaking file handles like  
>> it does currently.
>> 
>> It is of course trivial to "fix" this by attaching a simple  
>> finaliser, but the fact that this is not done by default makes me  
>> suspect that there would be something fishy with this approach. So,  
>> what's the rationale for the current behavior?
>
> It's predictable.

Predictably buggy.

> Closing a channel is not only about releasing OS resources. Imagine the  
> channel is actually a pipe - closing it means to signal EOF, i.e. it's  
> a way of notifying another program about an event. This should not  
> happen behind one's back.

If your channel is a pipe and you need it to stay open then keep it
alive. If you need to control when it is closed than close it when you
want it to be close, which you can only do as long as it stays alive.

So this argument is realy not an argument.

Note that nobody suggested restricting closing of channels to just the
GC. Only to have the GC double check and close them before they leak. If
you do it right then nothing changes. But if you did it wrong the GC
will catch that.

> Closing a regular file would in deed be harmless, but there is no  
> generic way to identify such channels (in the OS).
>
> Gerd


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.

MfG
        Goswin