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 B0FB27ED27 for ; Tue, 29 May 2012 14:08:57 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsEABS7xE/ZSMDdlGdsb2JhbAA6CrQ0BAOBICIBAQEBCQsJCRQDJIIXAQEEATo/BQsLDhMlDwEEKCETh3wBCQmuHB+KBosDEIUhA5pTjRc X-IronPort-AV: E=Sophos;i="4.75,677,1330902000"; d="scan'208";a="145752618" Received: from fmmailgate01.web.de ([217.72.192.221]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 May 2012 14:08:57 +0200 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate01.web.de (Postfix) with ESMTP id CA4C01AF11524 for ; Tue, 29 May 2012 14:08:56 +0200 (CEST) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0MJCAc-1Sc5Jq16Ww-002m7e; Tue, 29 May 2012 14:08:56 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1SZLEN-0006D4-DK; Tue, 29 May 2012 14:08:55 +0200 From: Goswin von Brederlow To: Gerd Stolpmann Cc: Lauri Alanko , caml-list@inria.fr References: <1337601452.19263.0@samsung> Date: Tue, 29 May 2012 14:08:55 +0200 In-Reply-To: <1337601452.19263.0@samsung> (Gerd Stolpmann's message of "Mon, 21 May 2012 13:57:32 +0200") Message-ID: <87fwajtciw.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Provags-ID: V02:K0:H1ASSy8OqhDGJvM5HLPIhw/da5wTlVnQ+tyRPELUBld YSQPylWBkWoXa7CwV9tJKVgxziilSsahtwSkoBtR+uO1VpWixd zxwwYaotsRD+eFSSFY8Rw0rs0rySXkMqKQtsxsWVAKz3UXc8XA Ty0QHppBKk98fxofxyBBnVwiVyO2ZpwVn5MtOS1aw1BusBtwRq GXOddsJaJAWz5KOiYsF6A== Subject: Re: AW: [Caml-list] Channels not closed on gc? 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. > 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. 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. MfG Goswin