#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