The result is a unified concurrency model providing both thread abstractions and event abstractions. We implemented the unified concurrency model in Haskell Our implementation demonstrates how to use these techniques by building an application-level thread library with support for multiprocessing and asynchronous I/O mechanisms in Linux. The thread library is type-safe, is relatively simple to implement, and has good performance. Application-level threads are extremely lightweight (scaling to 10,000,000 threads!) and our scheduler, which is implemented as a modular and extensible event-driven system, outperforms NPTL in I/O benchmarks.
This is an Erlang solution to "The Santa Claus problem", % as discussed by Simon Peyton Jones (with a Haskell solution using % Software Transactional Memory) in "Beautiful code". % He quotes J.A.Trono "A new exercise in concurrency", SIGCSE 26:8-10, 1994.
Peng Li's 2008 PhD dissertation, First, this dissertation presents a Haskell solution based on concurrency monads. This approach provides clean interfaces to both multithreaded programming and event-driven programming in the same application, but it also does not require native support of continuations from compilers or runtime systems. Then, this dissertation investigates for a generic solution to support lightweight concurrency in Haskell, compares several possible concurrency configurations and summarizes the lessons learned. The paper's summary explains what I like most about it: the project ... solves a systems problem using a language-based approach. Systems programmers, Haskell implementors and programming language designers may each find their own interests in this dissertation. Even if concurrency isn't your thing, section 6.3 describes the author's findings on the pros and cons of both purity and laziness in a systems programming context.
I didn't see anyone post them yet, so here are the slides from Tim Sweeney's POPL talk entitled "The Next Mainstream Programming Languages: A Game Developer's Perspective". I know Tim and I aren't the only game developers who follow LtU, and I figure even non-game developers might find them quite interesting!
One of those things I have to do fairly often in multithreaded programming is send off a whole bunch of threads to do their thing while I do something else on the main thread until they’re done. For example, imagine you’re downloading a bunch of images from the web, you don’t want to call httpGet one image right after another, because network resources are slow and processing them takes up almost no CPU time. But on the other hand, forkIO doesn’t return anything, so a thread thunk will have to put its contents somewhere you can access them later. Thus, my short, simple solution, far too small to bother putting up on Hackage: module Control.Concurrent.Future where import Control.Concurrent future :: IO a -> IO (MVar a) future thunk = do ref <- newEmptyMVar forkIO $ thunk >>= putMVar ref return ref forceAll :: [MVar a] -> IO [a] forceAll = mapM takeMVar