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
next prev parent 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