[GHC] #9539: TQueue can lead to thread starvation

[GHC]

#9539: TQueue can lead to thread starvation
-------------------------------------+-------------------------------------
        Reporter:  jwlato            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Core Libraries    |              Version:  7.8.2
      Resolution:                    |             Keywords:  stm
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by winter):

 Replying to [comment:12 dfeuer]:
 > I'm 90% confident this is not actually fixed. We now get good results
 from `atomically $ do {...; readTQueue q}`. Unfortunately, I believe the
 exact same problem will still occur as soon as we go a little further,
 with `atomically $ do {... ; !x <- readTQueue q; return x}`. I believe the
 only true solution is to base `TQueue` on a real-time queue rather than an
 amortized one.

 The original fix is straightforward, maybe we should add some documents to
 stop people explicit forcing the list reverse during transaction? The
 point is that after transaction finished, forcing thunk will only bring
 contention on blackhole, which will not stop consumer from making
 progress, thus solving the original issue perfectly.

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