From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id ADF06BC48 for ; Wed, 9 Mar 2005 23:45:43 +0100 (CET) Received: from first.in-berlin.de (dialin-145-254-051-108.arcor-ip.net [145.254.51.108]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j29Mjc9w024399 for ; Wed, 9 Mar 2005 23:45:41 +0100 Received: by first.in-berlin.de (Postfix, from userid 501) id 559C0B5F1F; Wed, 9 Mar 2005 23:45:32 +0100 (CET) Date: Wed, 9 Mar 2005 23:45:31 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: exception safety / RAII Message-ID: <20050309224531.GE321@first.in-berlin.de> References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071710.52544.jon@jdh30.plus.com> <87zmxc99g5.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> <200503091619.40419.jon@ffconsultancy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503091619.40419.jon@ffconsultancy.com> User-Agent: Mutt/1.5.6i X-Miltered: at concorde with ID 422F7C92.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; oliver:01 bandel:01 oliver:01 in-berlin:01 caml-list:01 ocaml:01 ocaml:01 implicitly:01 implicitly:01 run-time:01 unspecified:01 unspecified:01 deallocation:01 48,:98 freeing:98 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Wed, Mar 09, 2005 at 04:19:40PM +0000, Jon Harrop wrote: > On Wednesday 09 March 2005 14:48, you wrote: > > >> Very rarely having problems with something can't save it from being > > >> a very bad practice. Not explicitly closing your files is (in 99% of > > >> the cases) just sloppy coding. > > > > > > If we're talking about programs which are expected to run for an > > > arbitrary amount of time (servers, the top-level etc.) then yes. > > My statements were based on the incorrect assumption that the OCaml GC closes > files when it collects file handles. As this is not the case, I definitely > agree with you that not explicitly closing files in OCaml is sloppy coding > because they will not be closed implicitly. > > However, provided you don't need to make any guarantees about when the file is > closed during the running of the program, I still think that implicitly > closing a file (or deallocating an external resource) via the GC is not > sloppy coding. Indeed, this facility can be very useful and can eliminate an > important class of run-time errors. > > > This logic is routinely used in C to simply never call `free' because they > > only run for a short time. That's a textbook example of "sloppy coding". > > I wouldn't advocate never calling free() in a C program, but what is the > difference between calling free at some unspecified point in the future and > relying on a GC? I'm not a GC-expert, but it seems obvious to me, that a GC frees ressources at unspecified time and that also means at unspecified time in respect to the code that is executed. But calling a free() at a certain point in a program means that the deallocation is done at a certain time (in respect to code that is executed, even when not in certain real time in seconds). So, a free() in C is not unspecified, as it is called at a certain section of code. The GC frees ressources not as long as they are in use, but that they are not in use does not mean that they are *immediately* freed by the GC. It depends on statistical/stochastical things (not to determine). And that's the difference. To say a GC that it has to free ressources immediately, something like a GC-free-flush or something like that seems a littlebid like going back to free(). (Well, it's not the same, because the GC handles the "references" of which values are needed and which are not needed anymore, so a trigger to the GC to free ressources is not the same as writing code in C that does a free()-call. But normally it should be easier programming when the programmer does not necessarily have to think about freeing of GC-ressources.... normally the GC should be intelligent enough to handle it by itself.) (Rare cases may be there, where it is necessary to invoke GC-specific functions.) Ciao, Oliver