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 09DAEBC48 for ; Tue, 8 Mar 2005 02:09:40 +0100 (CET) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2819dlR018870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2005 02:09:39 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay01.plus.net with esmtp (Exim) id 1D8TDv-000L0d-97 for caml-list@yquem.inria.fr; Tue, 08 Mar 2005 01:09:23 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: exception safety / RAII ? Date: Tue, 8 Mar 2005 01:10:21 +0000 User-Agent: KMail/1.7.1 References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071729.20117.jon@jdh30.plus.com> <877e9a1705030710476502ad31@mail.gmail.com> In-Reply-To: <877e9a1705030710476502ad31@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503080110.21839.jon@jdh30.plus.com> X-Miltered: at concorde with ID 422CFB53.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 o'caml:01 ocaml:01 incorrectly:01 deallocated:01 finalizers:01 o'caml:01 dependencies:01 ...:98 frog:98 wrote:01 wrote:01 exception: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 18:47, Michael Walter wrote: > On Mon, 7 Mar 2005 17:29:19 +0000, Jon Harrop wrote: > > Would you mind elaborating a little on what you do desire, i.e. what does > > "using" do in C#, when would you use it and how does this relate to > > OCaml? > > Sure. I hope the following answers all three questions at once: > > let using resource thunk = > try > let > result = thunk resource > in > dispose resource; > result > with > any_exception -> > dispose resource; > raise any_exception > > My O'Caml is not very fluent, possible "dispose resource" should read > "resource # dispose". Either is clear enough. > Basically, the idea is to deterministically > clean up resources, as early as possible (yes, "but it's not as early > as possible" is besides the point :-). In my experience this > simplifies resource management and reasoning about it. Yes, so you can use your code to do this in OCaml. My concerns with such code basically revolve around the possibility of incorrectly deallocating an external resource and then using it again. This is not possible if you rely on the GC but, as you say, the problem is then the lack of guarantees about when resources have been deallocated by what point in the code. Perhaps explicitly asking the GC to deallocate all such resources is a better solution? Depending on the circumstances, this could give a big performance hit though... > > Presumably this is only difficult in the more complicated case of a > > general dependency graph between objects? In particular, one which has > > cycles. What kinds of programs require such sophistication? > > I have no idea about with finalizers in O'Caml (hence my more > broad/general statement), but in other languages I've worked with > there are several limitations which all basically origin in the fact > that finalization order in these languages was non-deterministic. Ok, I have found that, with a little thought and careful design beforehand, this is not a problem in OCaml. In the case of DAG dependency graphs, my solution is to represent the dependency graph for the GC by maintaining a list of references to dependees in each object. This forces the GC to respect dependencies when collecting. If the dependency graph is allowed to contain cycles then this might not work. I'm not sure though. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists