Hi Alain,

> What are the advantages of this approach over multi-processing (+
> explicit shared memory)?  Multi-processing brings extra isolation and
> safety; and it requires no change to the runtime system or the FFI.

Multi-processing has several drawbacks: you have to either create
several binaries for different tasks (master and workers usually), or
use options for that; you have to define a way to setup the system, for
example the master has to launch the workers, and for that, you have to
know where binaries are installed. On the contrary, with the "ocaml
fork" approach, you just have one program executing, so you can assume a
smaller knowledge of the environment.

For the FFI, I think it is actually possible to keep some
backward-compatibility, by allowing both a new kind of external C
functions (taking a thread specific context as argument, and declared
with the "reentrant" flag introduced by Sylvain) and the former kind
(without the context). Each function of the runtime would come in both
kinds, for example "caml_alloc_r" taking the context as extra argument,
and "caml_alloc"  without the context, the latter being a wrapper for
the former, with a way to recover the context in the middle (either
through TLS or thread specific). Most stub libraries would probably work
without change, maybe with a little extra-cost (actually, I think TLS is
costless, and thread specific is very efficient on Mac OS X where TLS
does not exist).

> One advantage of the approach you describe is that it would allow to use
> native libraries that support multi-threading. Do you see other advantages?

As I said before, the main one for me is the ability to setup everything
in one process, you can for example create locks, shared segments and
other synchronisation primitives in the main thread, before creating the
other threads, which is a little more difficult with multi-processing.

Cheers,
-- 
Fabrice