Re: [Caml-list] ocaml and concurrency

[Alex Baretta <alex@baretta.com>]

james woodyatt wrote:
> On 28 Jan 2004, at 15:26, Chet Murthy wrote:
 >
> I've almost finished convincing myself that <snip/>
 > the multi-threaded programming environment itself
> should be considered harmful and wrong and Just Say No, Kids.
> 
> But to write concurrent services without threads, you have to use a lot 
> of higher-order functions and non-blocking I/O functions.  Hey, guess 
> what?  Ocaml is a pretty good language for mixing functional programming 
> with imperative programming.  What if the *right* way to get concurrency 
> really *is* the ancient Unix dogma of 1) use heavyweight process 
> switching and message passing between processes, and 2) use monolithic 
> event loops inside lightweight programs?
> 
> I'm still working on a demonstration of the concept.  Please mind the gap.

Of course you are free to use the lower level abstractions if you like 
them better, but it gives you no more safety than threads. It's like 
flying your own jet plane because you are suspicious of pilots. Well, 
are you not a pilot if you fly your own plane? And are not 
reimplementing a (limited) multithreading model when you use Unix.select 
to choose a descriptor ready for IO?

Concurrency is neither good nor bad: it's just a part of modern 
interactive information systems. You've got to cope with it. It takes 
competence and adequate tools. I beleive that the message passing model 
implemented in the threads library's Event module is great abstraction 
with which to cope with the intricacies of concurrency. If this library 
had support for marshalling events through channels with an underlying 
file descriptor, Event would give me all the facilities I need for 
concurrency and distributed parallel processing.

Yet the neither the solution nor the problem are ever in the tool, but 
in the tool's user. You can implement distributed concurrent 
applications with Unix.select. Or, if you cannot trust the real-tiime 
capabilities of your Unix kernel, you can always code your own 
kernel--this is what a number of companies actually do (i.e. Cisco, with 
its proprietary OS) but whether their systems are more or less 
trustworthy than a Linux or BSD box is doubtful.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners