Browse thread
[Caml-list] ocaml killer
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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, mailto:skaller@tpg.com.au snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net ------------------- 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