#11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: mc.schroeder Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2011 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mc.schroeder): Actually, instead of simply locking all TVars involved in a finalizing transaction, my implementation "freezes" them, meaning they can still be read by other transactions (preserving read-parallelism). Only when another transaction tries to commit a write to a frozen TVar is its thread blocked. It is woken up again when the finalizer that froze the TVar has finished. Of course, this could take a while (potentially forever), and all transactions waiting on frozen TVars are stalled in the meantime. However, I would say that this is exactly the point of finalizers: they create a serialization point. As for the potential of deadlocks due to nested transactions: a deadlock could only occur if the inner transaction writes a TVar used by the outer transaction. In my opinion, this is a rather artifical scenario, that is unlikely to happen by accident. It will also always be detected by the runtime system, which would then gracefully abort the transaction with a BlockedIndefinitelyOnSTM exception. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11713#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler