English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
How INRIA people envision OCaml's parallel future?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-06-24 (16:59)
From: Eric Stokes <eric.stokes@c...>
Subject: Re: [Caml-list] How INRIA people envision OCaml's parallel future?
On Jun 24, 2005, at 5:50 AM, David MENTRE wrote:

> [ Last email, I swear it! ;-) ]
> Hello,
> 2005/6/24, David MENTRE <david.mentre@gmail.com>:
>> Anyway, INRIA people have already worked on those issues and had
>> proposals. It is just that they feel it was not worth the trouble,  
>> *at
>> that time*:
>> http://groups.google.com/groups?q=doligez+parallel+GC+caml- 
>> list&hl=fr&lr=&selm=fa.dlqoshv.1a66ho7%40ifi.uio.no&rnum=2
> From private and public emails, it appears that I have fed an old  
> troll.

Don't worry about it, it really is a valid issue that needs to be  
evaluated again every so often. Its true that many people have  
noticed the new multi core trend. However it has to be asked whether  
threads are really the right answer. They can honestly become a  
nightmare quite quickly.

> My intent is not to start another thread about GC and threading. My
> intent is to know how, in a short future, I could efficiently use a
> moderately SMP machine by writing pure OCaml code.

You sound like you need something right now, as well as in the  
future. So let me suggest a few tools that you might use to scratch  
your itch right now in the vein of typed channels.

1. Gerd Stolpman has one of the best XDR RPC libraries written for  
any language, it can certainly help improve the safety of a parallel  
program a lot by enforcing that data is exchanged in a type safe  
fashion, and it is also quite fast. It has a very nice rpc compiler  
which allows one to specify fairly painlessly the structure of  
messages. For your purposes, you could use unix domain sockets for  
transport, perhaps even using socketpair to avoid book keeping on the  
filesystem. http://ocaml-programming.de/packages/

2. If you prefer ASN.1 and BER, a subset of BER is included with my  
ldap library, although it is somewhat less nice than the current XDR  
library, it is functional, and also quite fast. http:// 

> It could be with typed channels between unix processes, by modifying
> the GC, by using concurrent constructs within the language, ... I
> don't know so this is why I'm asking it here.
> Yours,
> d.
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs