[Haskell-cafe] MVar considered harmful
ian at zenhack.net
Wed Dec 19 22:14:47 UTC 2018
A few thoughts:
* IIRC, MVars (in Haskell anyway) also have some fairness guarantees,
which I don't see otherwise mentioned in the discussion so far.
Compare to STM, where large transactions are susceptible to
* If the goal is to have a simpler base primitive on which to build,
everything has to boil down to compare-and-swap,
load-linked/store-conditional, etc -- whatever the machine provides.
When you start talking about even mutexes and semaphores, you're
already dealing with higher-level abstractions, so the thinking about
what's the right "primitive" seems silly to me at that point; you
should be thinking about what the high-level (user) code should be
able to do, and then figure out how to meet in the middle.
* If what you're after is *composable* concurrency, simpler locks won't
get you that. STM is the best general solution I've seen for this, and
if you're doing concurrency stuff in Haskell, I would say use STM
unless you have a specific reason to do something else.
* Re: async exceptions, you're in the same situation with MVars as you
are with all resource-acquiring IO actions in Haskell. `withMVar` and
friends cover async-exception safety, and you can't get rid of mask and
friends by swapping out MVars with another primitive anyway, because
you still need them for acquiring other (non-concurrency related)
resources, like files.
More information about the Haskell-Cafe