From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr 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 8991ABB81 for ; Fri, 11 Nov 2005 19:00:07 +0100 (CET) Received: from [127.0.0.1] (yquem.inria.fr [128.93.8.37]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jABI05P7029871 for ; Fri, 11 Nov 2005 19:00:07 +0100 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <878xvv1c2n.fsf@mid.deneb.enyo.de> References: <878xvv1c2n.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F807F11-D671-41F1-9EAE-C05BC6AE8406@inria.fr> Content-Transfer-Encoding: 7bit From: Damien Doligez Subject: Re: [Caml-list] Finalization and object dependencies Date: Fri, 11 Nov 2005 19:00:15 +0100 To: caml-list X-Mailer: Apple Mail (2.746.2) X-Miltered: at nez-perce with ID 4374DC25.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; damien:01 damien:01 caml-list:01 dependencies:01 arrays:01 handler:01 arrays:01 pointers:01 pointer:01 ocaml:01 2005,:98 ...:98 signaling:98 ...:98 wrote:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Nov 11, 2005, at 15:41, Florian Weimer wrote: > I've got to different types of objects, say database tables and > cursors for one table. Caml code is expected to access these objects > using some handle reference. > > [...] > > * When the program exits, all cursors and tables shall be closed, > even if the program was termined by an exception. > > (Here, "to fail" means to raise an exception or some other kind of > deterministic error signaling mechanism.) This will be hard to do if you really want to be complete. Some run- time errors (most notably, "out of memory") are not exceptions, they stop the program immediately. Moreover, under Unix there are signals that cannot be caught or ignored. > There are a couple of approaches to implement the desired behavior: > > (1) Just use weak arrays of tables and cursor, together with > Gc.alarm. > > (2) Use Gc.finalise for handler objects which contain an index into > (plain) arrays of tables and cursors. Use reference counting > (or back pointers) to prevent premature finalization of table > objects while there are still cursors around. A simple pointer from the cursor to the table should be enough. > (3) Same as (2), but using custom blocks and C code. You'd need reference counts in this case. I can't see how (1) would work. (2) is normal if your objects are implemented as OCaml data structures. (3) if they are implemented by some C library. > I'm not exactly happy with each appraoch because it seems I must > implement a simple memory manager on my own for managing the array > elements. Perhaps I'm missing something? Maybe simply that when you implement a program, you have to do some of the work, the GC cannot do everything for you... > How is the performance of the three approaches? Each one uses a > different GC mechanism to achieve its goals, so I'm a bit puzzled. Different mechanisms for solving different problems. -- Damien