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