From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p2P9taZ4005412
	for <caml-list@sympa-roc.inria.fr>; Fri, 25 Mar 2011 10:56:20 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: An0CAFxmjE3B/BfSkWdsb2JhbAClZgEBAgkLCwcUJcQUhWkEjHWDVA
X-IronPort-AV: E=Sophos;i="4.63,242,1299452400"; 
   d="scan'208";a="79046973"
Received: from msa01.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.210])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 25 Mar 2011 10:55:31 +0100
Received: from [192.168.1.63] ([83.204.241.208])
	by mwinf5d04 with ME
	id PMvX1g0044WVC3X03MvXFr; Fri, 25 Mar 2011 10:55:31 +0100
Message-ID: <4D8C6694.7060500@frisch.fr>
Date: Fri, 25 Mar 2011 10:55:32 +0100
From: Alain Frisch <alain@frisch.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>
CC: caml-list@inria.fr
References: <2054357367.219171.1300974318806.JavaMail.root@zmbs4.inria.fr> <4D8BD02D.1010505@inria.fr>
In-Reply-To: <4D8BD02D.1010505@inria.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] Efficient OCaml multicore -- roadmap?

Hi Fabrice,

On 03/25/2011 12:13 AM, Fabrice Le Fessant wrote:
>    Actually, I had a discussion two weeks ago with Xavier and Damien
> about this issue. There is some kind of agreement that the ocaml way of
> supporting multicore would be to have several runtimes running in the
> same process, in different threads. That way, the GC would still be
> mono-threaded, so almost no speed loss for mono-threaded programs (i.e.
> currently all OCaml programs ;-) ). There would be some kind of "fork"
> function, that would create a new thread running a function in a new
> heap, probably generated by a copy-on-need algorithm. The different
> threads would not share heap memory, but would be allowed to share
> structures outside of their heaps, probably for simple types like
> strings and int/float arrays (or using the Ancient library).

This sound very reasonable, and it's good to know that the subject is 
being discussed.

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.

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?


Cheers,

Alain