From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 83C44BC84 for ; Mon, 7 Mar 2005 18:09:54 +0100 (CET) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j27H9s6f006027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Mar 2005 18:09:54 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1D8Ljo-000GKv-Mz for caml-list@yquem.inria.fr; Mon, 07 Mar 2005 17:09:48 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: exception safety / RAII ? Date: Mon, 7 Mar 2005 17:10:52 +0000 User-Agent: KMail/1.7.1 References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071330.49084.jon@jdh30.plus.com> <87oedvcypd.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> In-Reply-To: <87oedvcypd.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503071710.52544.jon@jdh30.plus.com> X-Miltered: at nez-perce with ID 422C8AE2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 implicitly:01 finalizer:01 finalizer:01 subjective:01 deallocated:01 lablgl:01 deallocated:01 afaik:01 implicitly:01 ocaml:01 frog:98 wrote:01 exception:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Monday 07 March 2005 14:37, Stefan Monnier wrote: > > I very rarely have problems with this. > > 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. However, many programs run for a short time and, in these cases, I believe that OCaml guarantees to close your files at least upon program termination, if not before. Therefore, I would say that implicitly deallocating external resources is not sloppy coding in general. > Kinda like letting a GC finalizer close > your windows: when the effect is visible from outside the process it > shouldn't be done in a finalizer. The term "visible" in this context is subjective. People could look to see when you close your file, or they could make other measurements to determine whether or not you had deallocated an external resource, but unless this is likely to cause a problem I wouldn't worry. In the case of closing windows, I agree that would be sloppy coding. If you were talking about resources which the window had required and which the window manager is not likely to run out of, I wouldn't call it sloppy coding. In the case of lablGL not guaranteeing that OpenGL and context resources are deallocated in the proper order, this has never caused a problem for anyone AFAIK and it would be tricky to fix so I don't worry about. I'd like to fix it, yes, but it isn't at the top of my priority list because it doesn't cause a problem. In the case of me implicitly deallocating OpenGL display lists, this is never likely to cause a problem in practice so I'll probably never have to worry about. A user could still determine that I don't deallocate them immediately though, so you could still say that it is "visible". I also think that this discussion ties in with OCaml and soft real-time tasks. In theory, OCaml should not be good for such tasks because the GC could act unpredictably. In practice, I find that OCaml is perfectly good for soft real-time. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists