From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 49B2CBCAE for ; Fri, 24 Jun 2005 19:02:46 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j5OH2jlI020522 for ; Fri, 24 Jun 2005 19:02:45 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA23531 for ; Fri, 24 Jun 2005 19:02:45 +0200 (MET DST) Received: from mailx.valdosta.edu (mailx.valdosta.edu [168.18.130.251]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5OH2iQ2027294 for ; Fri, 24 Jun 2005 19:02:45 +0200 Received: from blazemail.valdosta.edu (valdosta.edu [168.18.130.208]) by mailx.valdosta.edu (8.13.4/8.13.4) with ESMTP id j5OH2g8a007485; Fri, 24 Jun 2005 13:02:42 -0400 (EDT) (envelope-from jtbryant@valdosta.edu) Received: from starlight.valdosta.edu (starlight.valdosta.edu [168.18.148.146]) by blazemail.valdosta.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTP id <0IIL00A5DM0I83@blazemail.valdosta.edu>; Fri, 24 Jun 2005 13:02:42 -0400 (EDT) Date: Fri, 24 Jun 2005 13:02:55 -0400 From: Jonathan_T_Bryant Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future? In-reply-to: <1119630886.18424.1.camel@calaf.rn.informatics.scitech.susx.ac.uk> To: David.Teller@ens-lyon.org, caml-list@inria.fr Reply-To: jtbryant@valdosta.edu Message-id: <1119632575.16349.23.camel@starlight.valdosta.edu> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-13) Content-type: text/plain Content-transfer-encoding: 7BIT References: <3d13dcfc05062300215e4be9ee@mail.gmail.com> <1119547256.4675.12.camel@starlight.valdosta.edu> <1119603126.8485.4.camel@localhost.localdomain> <3d13dcfc050624023670d3aed2@mail.gmail.com> <3d13dcfc050624055027743339@mail.gmail.com> <1119629698.16349.10.camel@starlight.valdosta.edu> <1119630886.18424.1.camel@calaf.rn.informatics.scitech.susx.ac.uk> X-PMX-Version: 5.0.1.144180, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.24.18 X-Miltered: at concorde with ID 42BC3CB5.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42BC3CB4.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml's:01 pointer:01 ocaml:01 ocaml:01 heap:01 params:01 params:01 heap:01 typecheck:01 cheers:01 semaphores:01 simulate:01 threads:01 shm:98 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: A shared memory segment is just a void pointer (in C), but the problem is that the static typing in OCaml does not allow that kind of lunacy, thank God. I guess that internally OCaml could see it as an array of some type and do some basic memory management on its own. Or, while slightly more sophisticated and complicated, maybe it could serve as a non-garbage collected static sized heap (OCaml would have to do some memory management, though). For example: Shm.get *some params* : Get a segment Shm.attatch *param* : Attatch Shm.detatch *params* : Detatch Shm.control *params* : Control the segment Shm.to_shared_heap *param* : Move something on the main heap to this heap Shm.to_gc_heap *param* : Move something from this heap to the main GC-ed heap Like all of my comments on this subject, I'd like to remind everyone that I'm not a GC expert or a language expert, but a code jockey. I just know what would make my life easier. On Fri, 2005-06-24 at 17:34 +0100, David Teller wrote: > How would you handle the shared memory ? > > I'm all for typed channels between processes, though. Although I don't > know how you could typecheck this, except perhaps by doing it the Acute > way (i.e. new names, which can be distributed). > > Cheers, > David > > On Fri, 2005-06-24 at 12:14 -0400, Jonathan_T_Bryant wrote: > > Well, one of the easiest ways is to extend the Unix library to be able > > to include the shared memory and semaphores system calls (shmget, shmat, > > shmctl, shmdt, semget, semctl, and a couple of others, too). That way > > heavyweight processes could simulate threads (they CAN take advantage of > > multiple processors but can also share data. That would be the easiest > > way to "solve" (if only partially) the problem. > > > > --Jonathan > >