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 (18:25)
From: skaller <skaller@t...>
Subject: Re: [Caml-list] ocaml and concurrency
On Thu, 2004-01-29 at 19:53, james woodyatt wrote:
> On 28 Jan 2004, at 15:26, Chet Murthy wrote:

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

See Felix. 

A large amount of 'need' for concurrency is
actually a need for control inversion. Event driven
programs are efficient  but almost impossible to structure
correctly: this is because a lot of state in block structured
code is maintained on the stack and identified by the current
value of the program counter: when you're programming directly
with an event loop, you have to maintain all that state manually.

In Felix, the programmer writes 'threads' and calls the 'read'
primitive to get the next message. This is no different
to calling C's 'read' function to read from a file, except
the context switching is done in user space. 

The architecture would usually be several threads or
processes to load the message queue, and a a small number
of independent worker threads (typically one per CPU)
to deliver the messages to the client threads synchronously.
[The worker threads are event loops ..]

I personally believe this architecture is useful in a 
wide class of applications, for example almost all
kinds of servers. However, asynchronous (pre-emptive)
context switching with shared data is certainly 
needed in many situations where neither cooperative
multi-tasking nor processes are suitable..

.. for example even in the above architecture, threads are
useful for loading the central message queue,
even if all they're doing is synchronising with
the processes actually procuring the messages.

John Max Skaller,
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix:

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: