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

[Gerd Stolpmann <info@gerd-stolpmann.de>]

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

My argument is that closing the channel would be worse than current
behavior, because the close action can cause additional effects, like
that the program at the other end of the pipe interprets the EOF it sees
then. If the close is unintentional (by forgetting to keep the channel
alive), this will be surprising. If the close is intentional (by a
missing explicit close), the close will happen at an unpredictable point
in time. Both effects make it difficult to diagnose the problem, and
will probably be recognized as "random effects" by the programmer.

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

I cannot follow. We discuss here how to handle a programming error, like
forgetting to keep the channel open, or forgetting to close the channel
explicitly, and the question whether the GC is helpful handling this.

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

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.

Gerd

> MfG
>         Goswin
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------