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=none 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 0D145BC6B for ; Tue, 8 Jan 2008 21:55:29 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADtyg0fAXQImh2dsb2JhbACQGwEBAQgKKZkR X-IronPort-AV: E=Sophos;i="4.24,259,1196636400"; d="scan'208";a="21032390" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Jan 2008 21:55:28 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m08KtRqW014890 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 8 Jan 2008 21:55:28 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADtyg0eoEoL7n2dsb2JhbACQGwEBAQEHBAYJIJkR X-IronPort-AV: E=Sophos;i="4.24,259,1196636400"; d="scan'208";a="21032389" Received: from mailx.valdosta.edu ([168.18.130.251]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Jan 2008 21:55:27 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPNxg0eoEoLQ/2dsb2JhbACpbw X-IronPort-AV: E=Sophos;i="4.24,259,1196658000"; d="scan'208";a="151743475" Received: from blazemail.valdosta.edu ([168.18.130.208]) by mailx.valdosta.edu with ESMTP; 08 Jan 2008 15:55:25 -0500 Received: from [168.18.160.118] (eurydice.valdosta.edu [168.18.160.118]) by blazemail.valdosta.edu (iPlanet Messaging Server 5.2 HotFix 2.10 (built Dec 26 2005)) with ESMTP id <0JUC00HMTFGDGB@blazemail.valdosta.edu> for caml-list@inria.fr; Tue, 08 Jan 2008 15:55:25 -0500 (EST) Date: Tue, 08 Jan 2008 15:55:24 -0500 From: Jonathan Bryant Subject: Re: [Caml-list] Parallelism with threads In-reply-to: <4783E08D.6040007@janestcapital.com> To: Caml List Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <200801081456.49677.jon@ffconsultancy.com> <4d5f7bec0801081131u2ebfae8aia0b13564d13b03c6@mail.gmail.com> <4783D640.7080800@janestcapital.com> <200801082023.47635.jon@ffconsultancy.com> <4783E08D.6040007@janestcapital.com> X-Miltered: at discorde with ID 4783E33F.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! 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 runtime:01 semantics:01 erlang:01 runtime:01 beginner's:01 On Jan 8, 2008, at 3:43 PM, Brian Hurt wrote: > 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. > Yes, this is the problem of not having a truly parallel GC. OTOH, what about adding a spawn command (in addition to Thread.create) which created a separate instance of the runtime (like you suggested) and used copy-on-write semantics for the heap? You still get the benefits of the same process (lightweight message passing, etc) with true SMP support but there is no need for a parallel GC since there are separate heaps. There is, of course, still the problem that communication channels still need to be shared between heaps somehow... As far as the Erlang Concurrency project from OSP, I can't say for sure but I'm pretty sure that it uses heavyweight processes to emmulate Erlang and doesn't modify the runtime. --Jonathan Bryant > Brian > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs