caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Richard Cole <rcole@itee.uq.edu.au>
To: caml-list@inria.fr
Subject: [Caml-list] Memory Mapped Files and OCaml
Date: Mon, 22 Mar 2004 15:05:08 +1000	[thread overview]
Message-ID: <405E7404.3050306@itee.uq.edu.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

Hi,

I wonder if anyone can give me some pointers. I'm interested in having 
all memory used by my ocaml program memory mapped so that calculations 
can be preserved from one run of an ocaml program to the next. I'm 
thinking of something like:

let empty_list : (string, string) list = [] in
*let user_list = store.get_value "user_list" empty_list in*
let user : string = Cgi.get_value "user" in
let password : string = Cgi.get_value "password" in
  if exists user user_list then
    if auth user password user_list then
      print_account_details user       
    else
      print_account_details user
  else
    begin
      *store.put_value "user_list" (add_user user password user_list);*
      print_account_details user
    end 

With the idea being that all values are stored in the memory mapped 
files so put_value and get_value are very fast. Serialization is ok for 
small data structures, but for 50M data structures, for which only a 
small part of the data structure is accesed, it is a pain.

The idea is that put_value and get_value cause structures to survive to 
the uppermost scope level and so these are not garbage collected before 
program termination since they are still referenced. Everything else 
gets garbage collected and so doesn't clog up the persistent store.

Of course program termination can take a long time if there are many 
dirty pages that need to be synchronised to disk. There may be some way 
to tell unix to sync dirty pages while the program is running but 
without thrashing (i.e. using all system resources).

Such a persistent store does suffer from a lack of safety. i.e. killing 
the process or the machine going down could leave the store in an 
inconsistent state. If safety is required there must be algorithms 
around to provide it in conjuction with a memory mapped file, perhaps 
via checkpointing. Does referential transparency help us here?

One final question: Are most people using database backends for 
persistence? Is it the case that most data structures that one would 
want to create in Ocaml programs map fairly easily into B-tree 
structures, i.e. are maps or multimaps from a keyed domain into some 
structured domain.

best regards,

Richard.


[-- Attachment #2: Type: text/html, Size: 2782 bytes --]

             reply	other threads:[~2004-03-22  5:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-22  5:05 Richard Cole [this message]
2004-03-22  9:40 ` Basile Starynkevitch
2004-03-23  7:21 ` Morphed at little into Grid Computing " Vasili Galchin

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=405E7404.3050306@itee.uq.edu.au \
    --to=rcole@itee.uq.edu.au \
    --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).