Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-11-30 (21:28)
From: Christophe Raffalli <craff73@g...>
Subject: Re: Threading and SharedMem (Re: [Caml-list] Re: Is OCaml fast?)
Le 30/11/10 22:13, Jon Harrop a écrit :
> What would be responsible for collecting the shared heap?
Reference counting: if there are no pointer within the shared heap (I
mean pointer
to and from the shared heap), this should be quite easy via a finaliser ...

For more than that, reference counting via finaliser + a real GC for the
shared heap itself,
because this heap being seen as a C region from OCaml, but using the
memory representation
of OCaml, it could be managed by your own GC.

So globally, I think writing a C program that would manage an OCaml
shared heap with its own GC and reference counting for the number of
pointer from OCaml threads is quite feasible ...

There remain the following problem of
- an unexpectidely dying OCaml thread would leave its refenrece counting
increased forever ... It is not clear we have to deal with that ...
- What syntax to allocate in the Shared heap (some camlpN (N = 4 or 5)
magic ?)
- There is something to do for pointers from the shared heap to some
OCaml heap, they have to be forbidden,
but maybe you would like to disallow their apparition at compile time by
some static analysis ... Anyway, they will be detected at runtime by
page violation when an OCaml thread tries to follow a pointer to the
heap of another thread. At least this page violation should be
transformed into an OCaml exception. They will also be detected by the
GC of the Shared heap ... An here it is not clear what to do ... Just
ignore them ?