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

[GHC]

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

Comment (by schyler):

 My understanding of how this would work is as follows.

 You start with 2 MVars:
 {{{
 m1 <- newMVar
 m2 <- newMVar
 }}}

 You then fuse them, as `MVar`s would [need to be extended to] have an
 inbuilt linked list of `StgMVar`s they actually represent:
 {{{
 mx <- fuseMVar m1 m2
 }}}

 Readers need to subscribe to every `StgMVar` in their list of `MVar`s (
 https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L1733 ). They
 should also write a pointer to the list of `MVar`s they are waiting on to
 their lightweight thread blocking reason (see below).

 Writers need to consider that the lightweight thread they are waking may
 already have been served, or even, processed data so fast they are re-
 subscribed into the queue in time to save their spot (unlikely, maybe this
 should be stopped with a gauge). Writers need to test the blocking reason
 for the lightweight thread (around
 https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L1611 ), and if
 it's blocking on something, ensure that they are in the supplied list of
 `StgMVar`s. This is actually only an O(n) operation to do, so it still
 costs O(1) + 1 branch if the `MVar` hasn't been fused.

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