Browse thread
How INRIA people envision OCaml's parallel future?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2005-06-24 (17:02) |
From: | Jonathan_T_Bryant <jtbryant@v...> |
Subject: | Re: [Caml-list] How INRIA people envision OCaml's parallel future? |
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 > >