caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Hale <hale@jhu.edu>
To: caml-list@inria.fr
Subject: [Caml-list] finalisers, Weak pointers
Date: Thu, 08 Aug 2002 10:09:11 -0400	[thread overview]
Message-ID: <6967B720-AAD8-11D6-A657-00039311FF84@jhu.edu> (raw)

Hi, does there exist any way to ensure that finalisers registered via 
the (undocumented) Gc.finalise
are called in order of their registration?

I have a program that deals in data structures that are collectively too 
big to all fit in main memory at once, and so I'd like to allow the 
garbage collector to decide when to write them out to disk files by
	(1) storing them in an array of Weak pointers
and
	(2) attaching finalisers who linearize the contents of array cells 
using the Marshal module.

as Damien Doligez writes in the stdlib/gc.mli,
>    A number of pitfalls are associated with finalised values:
>    finalisation functions are called asynchronously, sometimes
>    even during the execution of other finalisation functions.

(cf. http://caml.inria.fr/archives/200001/msg00011.html)

what I'm finding is that the finalisers sometimes get called in wacky 
orders such that `older' occupants
of the Weak array overwrite (on disk) what should be the current 
occupants. Is this just the "asynchronous" nature of the finalisers?

Is there any way to implement this kind of weak-pointer, disk-based 
backing store without having to "write-through" each time? In my 
particular case the data structures are variable-length so it seems only 
right that it be the Gc's decision whether they are too big to keep 
in-core.

thanks,
-john
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


                 reply	other threads:[~2002-08-09  9:31 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=6967B720-AAD8-11D6-A657-00039311FF84@jhu.edu \
    --to=hale@jhu.edu \
    --cc=caml-list@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).