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 072F9BC32 for ; Wed, 9 Mar 2005 02:21:05 +0100 (CET) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j291L4v6019282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2005 02:21:04 +0100 Received: from [80.229.56.224] (helo=chetara) by ptb-relay02.plus.net with esmtp (Exim) id 1D8psm-0008No-B0 for caml-list@yquem.inria.fr; Wed, 09 Mar 2005 01:21:04 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Re: exception safety / RAII ? Date: Wed, 9 Mar 2005 01:21:55 +0000 User-Agent: KMail/1.7.1 References: <293072a520e3724a0497e6456a8675be@mac.com> <200503080110.21839.jon@jdh30.plus.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503090121.55583.jon@ffconsultancy.com> X-Miltered: at concorde with ID 422E4F80.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 dependencies:01 afaik:01 dependencies:01 garbage:01 garbage:01 ocaml:01 pointers:01 mensagem:98 ...:98 frog:98 wrote:01 exception:01 incremental: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 Tuesday 08 March 2005 22:53, Daniel Yokomizo wrote: > "Jon Harrop" escreveu na mensagem > news:200503080110.21839.jon@jdh30.plus.com... > > 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. > > AFAIK it doesn't force the GC to respect the dependencies. An object is > garbage if it can't be reached from any root references, it doesn't matter > if other garbage objects still reference it. Yes, thank you for the more formal description. :-) Provided people want exactly this behaviour (which I do) then I believe that the approach I am using will work. You are quite right that this only respects dependencies between live objects and not between garbage objects. I haven't come across any tasks which require more sophisticated GC trickery, but I've no doubt that such tasks exist. I can't think of a good general solution which doesn't basically require you to implement your own GC in OCaml (weak pointers, incremental etc.). > IIUC the current OCaml GC implementation may exhibit such properties (i.e. > respect dependencies) but it isn't required to do so. Yes, the current GC may happen to deallocate things in the reverse of the order they were allocated in (this would explain why some things currently happen to work) but I've no idea if this really is the case. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists