#10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.2 (other) | Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): My use-case is this. Suppose a long-running transaction is repeatedly aborted because short-running transactions get in first. It might "starve". Then what? At the moment there is literally nothing the programmer can do because starvation is un-observable. Adding a retry handler makes it observable. Example: a librarian wants to re-organise the science fiction shelves of the library, but his long-running "reorganise" transaction is always aborted by someone doing a short-running "borrow-book" transaction. There is no automatic solution to this; it's an application-domain problem. For example, if the reorg became too long delayed, the librarian might temporarily close the SF section to borrowers. In the transactional setting, the retry handler might (in a separate, preliminary transaction) take a lock on the section, which borrowers must respect. None of this can happen unless the programmer can observe excessive retries and code a response. For example, she could count retries, and use an alternative strategy if the count got too high. (Actually, it might be convenient if the retry count was passed to the hander, so that the handler didn't need to create the state-and-increment stuff to manage the count.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10841#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler