From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 17DCCBC6B for ; Tue, 8 Jan 2008 21:43:59 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANJvg0dCm3xrnWdsb2JhbACCb40sAQEBARqZIw X-IronPort-AV: E=Sophos;i="4.24,259,1196636400"; d="scan'208,217";a="21032087" Received: from www.janestcapital.com (HELO smtp.janestcapital.com) ([66.155.124.107]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Jan 2008 21:43:58 +0100 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id A08D034C; Tue, 08 Jan 2008 15:43:57 -0500 Message-ID: <4783E08D.6040007@janestcapital.com> Date: Tue, 08 Jan 2008 15:43:57 -0500 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Parallelism with threads References: <200801081456.49677.jon@ffconsultancy.com> <4d5f7bec0801081131u2ebfae8aia0b13564d13b03c6@mail.gmail.com> <4783D640.7080800@janestcapital.com> <200801082023.47635.jon@ffconsultancy.com> In-Reply-To: <200801082023.47635.jon@ffconsultancy.com> Content-Type: multipart/alternative; boundary="------------050305010408080401060803" X-Spam: no; 0.00; parallelism:01 ocaml:01 runtimes:01 sockets:01 erlang:01 model:01 foo:01 foo:01 runtimes:01 mutable:01 ocaml:01 sockets:01 erlang:01 model:01 mutable:01 This is a multi-part message in MIME format. --------------050305010408080401060803 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Jon Harrop wrote: >On Tuesday 08 January 2008 20:00:00 Brian Hurt wrote: > > >>Actually, something that might be nice to see, now that the flat page >>table has been replaced with a heap that can handle disjoint heap >>spaces, is to allow multiple different Ocaml runtimes to be running in >>seperate threads in the same process. >>The heaps wouldn't be able to see each other, but they'd be able to >>communicate via light weight (and strongly typed) message passing, and >>you wouldn't have to dink around with sockets, pipes, MPI, or simiar >>"heavy weight" solutions, so it'd be simpler, and possibly faster. This >>is not unlike the Erlang model, in fact. >> >> > >This is exactly the kind of thing I'm interested in! > > > I take this back- I've just figured out it wouldn't work. Global variables would be seen as the same in both threads. Basically, if you had let foo = ref [ 1; 2; 3 ];; then the memory location foo would be seen by code in both runtimes, but the actual list elements would be in one thread and not the other. Worse yet, it's mutable data, so now you've got the possibility of a list going back and force between threads. Mass pandemonium breaks out. This is a bad idea. Brian --------------050305010408080401060803 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Jon Harrop wrote:

On Tuesday 08 January 2008 20:00:00 Brian Hurt wrote:

Actually, something that might be nice to see, now that the flat page
table has been replaced with a heap that can handle disjoint heap
spaces, is to allow multiple different Ocaml runtimes to be running in
seperate threads in the same process.
The heaps wouldn't be able to see each other, but they'd be able to
communicate via light weight (and strongly typed) message passing, and
you wouldn't have to dink around with sockets, pipes, MPI, or simiar
"heavy weight" solutions, so it'd be simpler, and possibly faster.  This
is not unlike the Erlang model, in fact.


This is exactly the kind of thing I'm interested in!

I take this back- I've just figured out it wouldn't work. Global variables would be seen as the same in both threads. Basically, if you had
let foo = ref [ 1; 2; 3 ];;
then the memory location foo would be seen by code in both runtimes, but the actual list elements would be in one thread and not the other. Worse yet, it's mutable data, so now you've got the possibility of a list going back and force between threads. Mass pandemonium breaks out.

This is a bad idea.

Brian

--------------050305010408080401060803--