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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 0CB65BC69 for ; Wed, 30 May 2007 22:06:23 +0200 (CEST) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4UK6MPf011915 for ; Wed, 30 May 2007 22:06:22 +0200 Received: from [192.168.0.104] (12-208-242-210.client.mchsi.com[12.208.242.210]) by sccmmhc92.asp.att.net (sccmmhc92) with SMTP id <20070530200621m9200d9kehe>; Wed, 30 May 2007 20:06:21 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070531055756.2e328baa.mle+ocaml@mega-nerd.com> References: <5F7D2956-2B0A-465A-8AC2-06D7EDC457F9@valdosta.edu> <4C7DF773-3B6F-464F-8D90-CE240B91AEE5@valdosta.edu> <20070531055756.2e328baa.mle+ocaml@mega-nerd.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <139AB75C-8B84-4E2A-AD75-09A7124D88FD@valdosta.edu> Content-Transfer-Encoding: 7bit From: Jonathan Bryant Subject: Re: [Caml-list] Faking concurrency using Unix forks and pipes Date: Wed, 30 May 2007 16:05:11 -0400 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.752.3) X-Miltered: at discorde with ID 465DD93E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; forks:01 marshaling:01 marshaled:01 runtime:01 node:01 misused:98 heap:01 heap:01 unix:01 caml-list:01 marshal:01 marshal:01 closure:01 closure:01 data:02 > >> I do have worries about the efficiency of this though: >> when marshaling a closure across a socket to another process, it >> must marshal all the necessary state as well. I would imagine this >> has the potential to get slow if there was much state to marshal >> (i.e., a closure marshaled referencing a large data structure). > > This is a potential problem. This is like so many language features > that if misused, can lead to huge performance degradations. Knowing > about the problem beforehand allows programmers to avoid it. Just throwing out an idea, so someone who is more familiar with the GC/runtime correct me if this can't be done, but what about a smaller separate heap in shared memory that is reserved for concurrent data? Maybe you could declare a type stype 'a tree = | Node of 'a * 'a tree * 'a tree | Leaf of 'a that is always allocated in the shared heap, and have a separate GC thread that manages that heap. Could that GC be concurrent without affecting the performance of non-concurrent data? --Jonathan