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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 629DCBC0A for ; Mon, 4 Jun 2007 18:15:07 +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 l54GF6PA019871 for ; Mon, 4 Jun 2007 18:15:07 +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 <20070604161505m9200dana7e>; Mon, 4 Jun 2007 16:15:06 +0000 In-Reply-To: <9b415f950706040850v586a285ax1448d23c0c78a375@mail.gmail.com> References: <200706041156.16521.jon@ffconsultancy.com> <67BC38F1-55DA-46F6-B35E-E728F7B1154B@valdosta.edu> <9b415f950706040850v586a285ax1448d23c0c78a375@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B7A6678-6C9E-4356-802C-5CA5168A27CC@valdosta.edu> Cc: caml-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Jonathan Bryant Subject: Re: [Caml-list] Faking concurrency using Unix forks and pipes (ray tracing results) Date: Mon, 4 Jun 2007 12:13:47 -0400 To: Benedikt Grundmann X-Mailer: Apple Mail (2.752.3) X-Miltered: at discorde with ID 46643A8A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; forks:01 grundmann:01 arrays:01 ocaml:01 threads:01 threads:01 functors:01 sig:01 val:01 val:01 sockets:01 hofs:01 runtime:01 cheers:01 2007,:98 On Jun 4, 2007, at 11:50 AM, Benedikt Grundmann wrote: > Hi Jonathan, > > 2007/6/4, Jonathan Bryant : >> >> On Jun 4, 2007, at 6:56 AM, Jon Harrop wrote: >> >> > >> > When you apply this map to an array, a new process is forked for >> > each element. >> > As forking is time consuming, you should only apply this to short >> > arrays. >> >> It might be worth your while to implement a process pool. I said >> before that I fork of one base process from which to fork the others, >> and it's not possible to make that process just a controller for a >> pool of waiting processes. >> >> --Jonathan >> > > Do you also do that in your work for the OSP? I'm asking cause you > mentioned previously that you want to stay compatible to the ocaml > threads library... and I just can not figure out how you want to > implement Thread.create using that base process... I'm staying with the feel of the threads library, but I'm going to have to make it incompatible. My API uses functors to build everything up and then resembles the existing API. I know there has been some talk on this list about performance issues with that, but I prefer a clean design over speed (at least at the moment). Mainly this is because Marshal is not trustworthy, so every message type needs to have to_ and of_ string functions: module type Message = sig type 'a t val to_string : 'a t -> string val of_string : string -> 'a t end From there it builds up. I'm actually trying to design it in such a way that channels aren't limited to UNIX/TCP sockets, and that the on-wire protocol can be changed as well. Hopefully that will go as planned. As for threads, there are actually 3 levels: concurrent (the existing threads), parallel (forked processes), and remote (forked process on another machine). The level of concurrency is specified at thread creation either by using a special version of Thread.create (such as Thread.concurrent or Thread.parallel) or by an optional parameter to Thread.create. This allows the programmer to use the mechanism needed (threads/processes) in the same manner. One additional change is that threads can either be attached (return a value), or detached (like they are now and return unit), allowing for a future-esque usage of threads. Also, since it's internally just HOFs filled in by the runtime, it allows programs written to run on a cluster (using remote threads) to run in a single process for testing (using just concurrent threads), and then moved to a multi-core / multi-machine environment without any recoding or recompilation. > BTW: Maybe we should subscribe each others project's mailing list? So > tha twe can help and learn from each other? > I'm already on yours :). Mine's http://groups.google.com/group/osp2007-northpole From what you've said, I think we might be covering a lot of the same ground. > > Here is the link to mine: > > http://groups.google.com/group/osp2007-econcurrency > > Cheers, > > Bene > > > -- > Calvin: I try to make everyone's day a little more > surreal. > > (From Calvin & Hobbes)