[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 arybczak):

 Let's revive this ticket and get it resolved.

 For what it's worth, readTBQueue uses lazy let for reverse and it's even
 appropriately commented: `NB. lazy: we want the transaction to be  short,
 otherwise it will conflict`.

 This issue makes me anxious to use TQueue in any real-world scenario
 because given sufficiently large spike in produced values it leads to
 memory exhaustion, as at some point the consumer will not be able to
 finish the transaction without conflicts even if rate of produced values
 goes down.

 I'm just going to attach a patch that makes the definition of readTQueue
 consistent with readTBQueue and we can go from there.

 If you know what exact benchmarks we need to run, please speak up.

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