caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Damien Doligez <damien.doligez@inria.fr>
To: caml-list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Finalization and object dependencies
Date: Fri, 11 Nov 2005 19:00:15 +0100	[thread overview]
Message-ID: <7F807F11-D671-41F1-9EAE-C05BC6AE8406@inria.fr> (raw)
In-Reply-To: <878xvv1c2n.fsf@mid.deneb.enyo.de>

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


  reply	other threads:[~2005-11-11 18:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-11 14:41 Florian Weimer
2005-11-11 18:00 ` Damien Doligez [this message]
2005-11-12 18:22   ` [Caml-list] " Florian Weimer
2005-11-17  1:42 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7F807F11-D671-41F1-9EAE-C05BC6AE8406@inria.fr \
    --to=damien.doligez@inria.fr \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).