Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] ocaml killer
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-01-29 (08:53)
From: james woodyatt <jhw@w...>
Subject: [Caml-list] ocaml and concurrency
On 28 Jan 2004, at 15:26, Chet Murthy wrote:
> [...]
> "concurrency"!  You ever tried to use Java threads to do anything
> meaningful?  Check out the J2EE spec.  It basically is BUILT around
> NOT sharing anything between threads.
> Oh, and y'know, we have a joke: "every Java bug is a connection-pool
> (or resource-pool) bug".
> Here's another: "When you arrive onsite,  grep for synchronized, and
> if you see it, put your laptop back in your bag, tell 'em you're going
> to get coffee, and don't come back".
> [...]

In my current day job, I get paid to code on an application for the 
VxWorks RTOS, a very multi-threaded environment.  I've been around 
multi-threaded programming environments for a long time now.  Since the 
late 1980's anyway.  That's no joke about 'every bug being a 
resource-pool bug'-- except in C/C++ (as well as Java probably), there 
are also the other two kinds of bug: the 'unprotected critical section 
bug' and the 'mutual exclusion deadlock bug'.

I've almost finished convincing myself that the main problem with the 
Java Runtime Environment (which I don't have much experience with, 
because I saw it as a train wreck waiting to happen back when the world 
was all jazzed to be getting Java 1.0 someday soon, and I avoided it at 
all costs) is that 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 

j h woodyatt <>
markets are only free to the people who own them.
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: