On Apr 7, 2005 10:47 PM, Yoann Fabre <Yoann.Fabre@wanadoo.fr> wrote:

> And of course, we cannot execute more than one Caml thread at a time...

See below.

[snip]

> So what can we do?
> Here's my two cents proposal for the short/long term:
> 
> Phase 1 - Maybe provide some module in the stdlib to:
> - allow easy management of multiple Caml /processes/
> - allow easy communication with message passing (MPI like + Marshal)
> - allow easy synchronisations between these pseudo-threads
> Phase 2 - Add another module to:
> - provide a standard interface to memory sharing
> - allow some awful dirty hack to GC-allocate some special blocks into that
> region? Some "custom2" with reference counting (ouch!) between the GCs
> Phase 3 - write a concurrent GC (CGC) (re-ouch!)

Instead you could try something like AliceML and Oz approach.  They
have a single runtime, but distribution support.  Oz makes it easy to
distribute a program being network transparent.  Alice, I'm not sure
about.  They do memory sharing on local machines and tcp on networks.

You gain parallelism by distributing the program.  Sure it's done
manually, but in some ways that's a plus.

I'm not sure if OCaml has distributed systems support, but if not an
alternative to your proposal would be to build distribution support
for ocaml.

> Well, I've studied a bit the CGC field and read Damien's Phd... It's
> frightening! But, to recast the issue in a somewhat broader context, can we
> really still pretend that a "modern" generic language can live without true
> concurrency in 2005?

Concurrency != parallelism.  


Chris