
#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