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
), MVar
s often require extra inefficient intermediate steps to funnel many-to-one.
A common thing for people to do when they need to funnel N MVar
s 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) MVar
s together into one which can be waited on and yield values from any of the containing MVar
s.
(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 |