[GHC] #14324: Consider deprecating STM invariant mechanism

[GHC]

#14324: Consider deprecating STM invariant mechanism
-------------------------------------+-------------------------------------
           Reporter:  bgamari        |             Owner:  (none)
               Type:  task           |            Status:  new
           Priority:  normal         |         Milestone:  8.6.1
          Component:  Compiler       |           Version:  8.2.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 fryguybob and I were recently discussing the STM invariant mechanism. This
 mechanism is, presumably, intended to expose problems from odd
 interleavings of transactions. However, fryguybob pointed out that the
 implementation currently takes so many locks that it very likely prevents
 these odd interleavings from occurring.

 In addition,
  * the implementation doesn't handle nested STM invariants correctly
 (#7930)
  * the locking behavior of the implementation was, until very recently,
 utterly wrong (#14310)
  * the feature introduces quite a bit of complexity in the RTS
  * the interface has essentially no users, as evidenced by a Hackage
 search and the fact that #14310 went unnoticed for years

 All of this raises the question: Is the STM invariants feature really
 where we want to spend our complexity budget? Perhaps it is time for this
 feature to quietly pass (after an appropriate deprecation period, of
 course).

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