From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 2D86A7ED26 for ; Tue, 29 May 2012 16:13:09 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4CAF7YxE/AbSoIe2dsb2JhbABEhTCwBSIBARYmBCOCFwEBBSNWEAsJBQoCAiYCAhQYMROICwSmHZI+FIEQiV+EHzJgA41Rh0WSVA X-IronPort-AV: E=Sophos;i="4.75,677,1330902000"; d="scan'208";a="145776663" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2012 16:13:08 +0200 X-Envelope-From: oliver@first.in-berlin.de Received: from first (e178013213.adsl.alicedsl.de [85.178.13.213]) (authenticated bits=0) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id q4TED3Zq030235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 May 2012 16:13:04 +0200 Received: by first (Postfix, from userid 1000) id 9F7F7154051D; Tue, 29 May 2012 16:13:03 +0200 (CEST) Date: Tue, 29 May 2012 16:13:03 +0200 From: oliver To: Gerd Stolpmann Cc: Goswin von Brederlow , Lauri Alanko , caml-list@inria.fr Message-ID: <20120529141303.GA4477@siouxsie> References: <1337601452.19263.0@samsung> <87fwajtciw.fsf@frosties.localnet> <1338295564.17140.33.camel@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1338295564.17140.33.camel@thinkpad> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Subject: Re: AW: [Caml-list] Channels not closed on gc? 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 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