caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: oliver <oliver@first.in-berlin.de>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: Goswin von Brederlow <goswin-v-b@web.de>,
	Lauri Alanko <la@iki.fi>,
	caml-list@inria.fr
Subject: Re: AW: [Caml-list] Channels not closed on gc?
Date: Tue, 29 May 2012 16:13:03 +0200	[thread overview]
Message-ID: <20120529141303.GA4477@siouxsie> (raw)
In-Reply-To: <1338295564.17140.33.camel@thinkpad>

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.


Ciao,
   Oliver

  reply	other threads:[~2012-05-29 14:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 11:23 Lauri Alanko
2012-05-21 11:57 ` AW: " Gerd Stolpmann
2012-05-21 12:53   ` Philippe Wang
2012-05-21 13:31     ` Gerd Stolpmann
2012-05-21 14:18       ` Philippe Wang
2012-05-21 14:48         ` Mehdi Dogguy
2012-05-29 12:08   ` AW: " Goswin von Brederlow
2012-05-29 12:46     ` Gerd Stolpmann
2012-05-29 14:13       ` oliver [this message]
2012-05-29 18:39         ` Török Edwin
2012-05-29 18:58           ` Philippe Veber
2012-05-29 12:49     ` Jérémie Dimino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120529141303.GA4477@siouxsie \
    --to=oliver@first.in-berlin.de \
    --cc=caml-list@inria.fr \
    --cc=goswin-v-b@web.de \
    --cc=info@gerd-stolpmann.de \
    --cc=la@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).