Avoiding BlockedIndefinitelyOnSTM exceptions

Gabriel Gonzalez gabriel439 at gmail.com
Mon Jul 14 02:30:18 UTC 2014


I have what may sound like an unusual request: I would like to 
automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a 
primitive that looks something like this:

     safe :: STM a -> STM (Maybe a)

This hypothetical `safe` primitive would attempt a transaction, and if 
`ghc` detects that this transaction would fail because of an 
`BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of 
throwing an uncatchable exception.

I originally simulated a limited form of this behavior using 
`pipes-concurrency`.  I instrumented the garbage collector (using weak 
references) to detect when an STM variable was garbage collected and to 
safely cancel any transactions that depended on those variables.  You 
can see the implementation here:

https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2dab472b7e4cde7bea31227a917ce5d5375/src/Pipes/Concurrent.hs#L170

The original purpose behind this was to easily read and write to a 
channel without having to count references to the channel.  I reasoned 
that the garbage collector *already knew* how many open references there 
were to channel, so I thought "why not use the garbage collector to 
gracefully cancel transactions that would block just before they would 
trigger the exception?"

This worked really well up until ghc-7.8 changed something and the above 
trick no longer works.  To be honest, I'm surprised that it ever worked 
at all, which is why I'm not requesting restoring the original 
behavior.  Instead, I think providing something like the above `safe` 
primitive would be nicer, if possible.

Would it be possible to implement something like `safe`?

Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` 
exception catchable?

P.S.  I'm also interested in learning more about what may have caused 
the change in behavior in the transition from ghc-7.6 to ghc-7.8.  What 
changes were made to the interaction between STM and weak references 
that may have triggered this?


More information about the Glasgow-haskell-users mailing list