[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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