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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 5F9EA7ED26 for ; Tue, 29 May 2012 14:46:10 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjICAMnDxE/U4366k2dsb2JhbAA6CoMdghOwKyIBAQEBCQkLCRQDJIIXAQEEASNWBQsLGgImAgJXBhMJh30JB6YDkjiBJIlfEIQPgRIDjSOJA4RAjQQ X-IronPort-AV: E=Sophos;i="4.75,677,1330902000"; d="scan'208";a="160388543" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail1-smtp-roc.national.inria.fr with ESMTP; 29 May 2012 14:46:10 +0200 Received: from office1.lan.sumadev.de (dslb-188-097-013-169.pools.arcor-ip.net [188.97.13.169]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MTJZq-1SPxuR2wZK-00RYzm; Tue, 29 May 2012 14:46:02 +0200 Received: from [192.168.5.106] (dslb-188-097-013-169.pools.arcor-ip.net [188.97.13.169]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 6A25AC00D0; Tue, 29 May 2012 14:46:00 +0200 (CEST) From: Gerd Stolpmann To: Goswin von Brederlow Cc: Lauri Alanko , caml-list@inria.fr In-Reply-To: <87fwajtciw.fsf@frosties.localnet> References: <1337601452.19263.0@samsung> <87fwajtciw.fsf@frosties.localnet> Content-Type: text/plain; charset="UTF-8" Date: Tue, 29 May 2012 14:46:04 +0200 Message-ID: <1338295564.17140.33.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:JUdxtn3cw1QvBKnIIh4SxvTPUdBLyXJEP1wAMPyD4bn 7mrvl2igOfDwUiRXEzxGnW6wB/zo8keIOycmJNqDZnQNlVKrBv lh2o24lSnr1LMpxAvZ3Z+Yy90c1/JeNDUxKSTnq+m//Vp9IGG/ uNMiDgXPJJv0IyKfPuS1DzKuoBVZxjK79WrFd+8eSj6Wxc3/Dq ij+eFctAH7DewnHrV82e/NqrE53TswMSCIJ0C8WQ2quk4S3HGk zUTBuW4VNIRSwoi0yXMov6+Cne4G5ef2FQyEq8uOZkKT//TxFX g5VEUNiSh5efCEICVDKOyt5phi1UMe3QHG5qN7+UF4KnsS5EXu 0WXUVQxIFg82Q7kPfd0U47nOsbF4xg9vSRQQbbGCC Subject: Re: AW: [Caml-list] Channels not closed on gc? 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. > >> > >> 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. ------------------------------------------------------------