Support for waiting on multiple MVars

A lot of code in servers uses MVars because they seem to have more desirable scalability characteristics than STM. Unfortunately, unlike STM which is composable (i.e. readTChan chan1 <|> readTChan chan2), MVars often require extra inefficient intermediate steps to funnel many-to-one.

A common thing for people to do when they need to funnel N MVars into one is to create 1 MVar and N forks where each fork attempts to read from its associated MVar and then writes it into the one MVar where another fork is waiting to process the data.

This is such a waste; it produces more forks and another MVar where contention can occur.

In some ways it would be better if the internal representation of an MVar had a pointer to the "next MVar" so that we could use a function like eitherMVar to merge two (or more) MVars together into one which can be waited on and yield values from any of the containing MVars.

(I believe) the runtime would need to provide appropriate support in the scheduler so that the list is traversed instead of only the single MVar checked. The overhead for code which does not use this feature would probably be only 1 branch, which is acceptable.

Trac metadata

Trac field	Value
Version	7.8.3
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	simonmar
Operating system
Architecture