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 2F8E8BC32 for ; Tue, 8 Mar 2005 23:54:55 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j28MssDt032715 for ; Tue, 8 Mar 2005 23:54:54 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA21073 for ; Tue, 8 Mar 2005 23:54:54 +0100 (MET) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j28MsrmC032712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2005 23:54:54 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1D8nWH-0003nz-9H for caml-list@inria.fr; Tue, 08 Mar 2005 23:49:42 +0100 Received: from 200-148-90-147.dsl.telesp.net.br ([200.148.90.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Mar 2005 23:49:41 +0100 Received: from daniel_yokomiso by 200-148-90-147.dsl.telesp.net.br with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Mar 2005 23:49:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: "Daniel Yokomizo" Subject: Re: Re: exception safety / RAII ? Date: Tue, 8 Mar 2005 19:53:44 -0300 Message-ID: References: <293072a520e3724a0497e6456a8675be@mac.com> <200503071729.20117.jon@jdh30.plus.com> <877e9a1705030710476502ad31@mail.gmail.com> <200503080110.21839.jon@jdh30.plus.com> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 200-148-90-147.dsl.telesp.net.br X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Sender: news X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner: Found to be clean X-Gmane-MailScanner-SpamCheck: spam, SpamAssassin (score=7.81, required 6, BAYES_00 -2.60, HELO_DYNAMIC_HCC 3.74, HELO_DYNAMIC_IPADDR2 3.50, PRIORITY_NO_NAME 1.10, RCVD_IN_NJABL_DUL 0.09, RCVD_IN_SORBS_DUL 1.99) X-Gmane-MailScanner-SpamScore: sssssss X-MailScanner-From: gclci-caml-list@m.gmane.org X-MailScanner-To: caml-list@inria.fr X-Miltered: at nez-perce with ID 422E2D3E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 422E2D3D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; finalizers:01 o'caml:01 ocaml:01 dependencies:01 afaik:01 dependencies:01 garbage:01 garbage:01 ocaml: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=1.2 required=5.0 tests=PRIORITY_NO_NAME autolearn=disabled version=3.0.2 X-Spam-Level: * "Jon Harrop" escreveu na mensagem news:200503080110.21839.jon@jdh30.plus.com... > On Monday 07 March 2005 18:47, Michael Walter wrote: [snip] > > 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. AFAIK it doesn't force the GC to respect the dependencies. A object is garbage if it can't be reached from any root references, it doesn't matter if other garbage objects still reference it. So if we have: ROOT -> A -> B -> C D -> E -> F G -> B H -> C the GC can collect any of [D, E, F, G, H], in any order it wants, because they're all garbage. An incremental collector could collect first [F, G, H] because they are (say) large objects, and don't recycle the memory for [D, E] until the next collection. IIUC the current OCaml GC implementation may exhibit such properties (i.e. respect dependencies) but it isn't required to do so. > 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