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


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
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