[GHC] #10841: Run handler on STM retry

[GHC]

#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