Version française
Home     About     Download     Resources     Contact us    
Browse thread
Finalization and object dependencies
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Damien Doligez <damien.doligez@i...>
Subject: Re: [Caml-list] Finalization and object dependencies
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