Re: [Caml-list] How INRIA people envision OCaml's parallel future?

[Jonathan_T_Bryant <jtbryant@valdosta.edu>]

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
> 
>