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 509187ED26 for ; Tue, 29 May 2012 14:50:37 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAPHExE/VuiYS/2dsb2JhbABEhGJOsCuBB4IXAQEEAQwXVgULCQIaAiYCAlcGE4d9AwYJpgqIXSKJOYEkiV+EH4ESA5UWj3KCYoFUIA X-IronPort-AV: E=Sophos;i="4.75,677,1330902000"; d="scan'208";a="160389399" Received: from solaria.dimino.org ([213.186.38.18]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 29 May 2012 14:50:37 +0200 Received: from caladan (caladan.dim [10.200.42.14]) by solaria.dimino.org (Postfix) with ESMTP id 4505380083; Tue, 29 May 2012 14:50:36 +0200 (CEST) Received: from caladan.esterel-technologies.com (localhost [127.0.0.1]) by caladan (Postfix) with ESMTP id 90B991000F3; Tue, 29 May 2012 14:49:48 +0200 (CEST) Date: Tue, 29 May 2012 14:49:47 +0200 From: =?UTF-8?B?SsOpcsOpbWll?= Dimino To: Goswin von Brederlow Cc: Gerd Stolpmann , Lauri Alanko , caml-list@inria.fr Message-ID: <20120529144947.605213ae@caladan.esterel-technologies.com> In-Reply-To: <87fwajtciw.fsf@frosties.localnet> References: <1337601452.19263.0@samsung> <87fwajtciw.fsf@frosties.localnet> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Channels not closed on gc? Le Tue, 29 May 2012 14:08:55 +0200, Goswin von Brederlow a =C3=A9crit : > 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. >=20 > So this argument is realy not an argument. >=20 > 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. Sometimes you have a file descriptor and you temporary create a channel for it. Once you are done with the channel you flush it (if it is an output channel) but you do not close it and continue to use the file descriptor. In this case automatically closing the channel (and so the underlying file descriptor) would be wrong. > 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. >=20 > 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. >=20 > 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. Not if you consider that a buffered channel is just an helper data structure on top of a read/write function. Cheers, --=20 J=C3=A9r=C3=A9mie