What happened to "Lightweight Concurrency Primitives for GHC"?

There is a 2007 paper entitled “Lightweight Concurrency Primitives for GHC” that motivates a design for slimming down RTS-provided concurrency primitives, and moving the implementation of forkIO/MVar/STM into a Haskell library.

There was a branch, too, but it hasn’t been updated since 2013.

Does anyone happen know what happened to this work?

7 Likes

It is work that I loved, but it’s 100% stalled for lack of cycles. KC (the moving force) is now doing other things, so it needs a new enthusiast, or band thereof.

A useful paper came out of it though:

A significant challenge will be getting good performance. Even if the result is more beautiful, everyone would have a hard time swallowing even an 10% slow-down across the board.

9 Likes

Where KC’s other things is working on OCaml Multicore (for those that didn’t know), adding concurrency expressed through effect handlers and parallelism through domains. I’m less familiar with the GHC proposal but at a superficial level there seems to be significant overlap.

1 Like

I’ve been wondering for some time now if it would be possible to implement concurrency based on parallelism - if so, all forms of concurrency could then be implemented as libraries, leaving the RTS parallelism-only.

Ideally, concurrency would end up being parallelism-with-effects (invariably I/O-based).

So the question is this: what are the potential and actual obstacles in GHC to making this possible?