Support for waiting on multiple MVars
|Reported by:||schyler||Owned by:||simonmar|
|Type of failure:||None/Unknown||Test Case:|
|Related Tickets:||Differential Rev(s):|
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
(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.