[GHC] #9321: Support for waiting on multiple MVars

[GHC]

#9321: Support for waiting on multiple MVars
-------------------------------------+-------------------------------------
        Reporter:  schyler           |                   Owner:  simonmar
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Runtime System    |                 Version:  7.8.3
        Keywords:  mvar              |  Differential Revisions:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
       Test Case:                    |              Difficulty:  Unknown
        Blocking:                    |              Blocked By:
                                     |         Related Tickets:
-------------------------------------+-------------------------------------
 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.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9321>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler