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

["Jérémie Dimino" <jeremie@dimino.org>]

Le Tue, 29 May 2012 14:08:55 +0200,
Goswin von Brederlow <goswin-v-b@web.de> a écrit :

> 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.

Sometimes you have a file descriptor and you temporary create a
channel for it. Once you are done with the channel you flush it (if it
is an output channel) but you do not close it and continue to use the
file descriptor. In this case automatically closing the channel (and
so the underlying file descriptor) would be wrong.

> 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.

Not if you consider that a buffered channel is just an helper data
structure on top of a read/write function.

Cheers,

-- 
Jérémie