Skip to content

STM: don't create a transaction in the rhs of catchRetry# (#26028)

Sylvain Henry requested to merge hsyl20/ghc:hsyl20/26028-stm-retry into master 
STM: don't create a transaction in the rhs of orElse (#26028)

We don't need to create a transaction for the rhs of orElse
(catchRetry#) because contrary to the lhs we don't need to abort it on
retry. Moreover it is particularly harmful if we have code such as
(#26028):

  let cN = readTVar vN >> retry
      tree = c1 `orElse` (c2 `orElse` (c3 `orElse` ...))
  atomically tree

Because it will stack transactions for the rhss and the read-sets of all
the transactions will be iteratively merged in O(n^2) after the
execution of the most nested retry.

One change in behavior is that we no longer try to commit the rhs
eagerly while exiting the catch_retry frame. For example consider:

  (e `orElse` (readTVar foo >> f)) >> g

Previously, if `foo` was modified at some point while executing `f`, `g`
would not even be executed: `stg_abort` would be called while committing
the nested transaction for the rhs of `orElse`. This is no longer the
case. This behavior wasn't documented anywhere, so it should be fine.

Note for the reviewers: I've never touched the stm code before, so maybe this change is bogus for some reason I missed!

Merge request reports