Avoiding BlockedIndefinitelyOnSTM exceptions

[wren romano]

On Mon, Jul 14, 2014 at 11:16 AM, Gabriel Gonzalez <gabriel439 at gmail.com> wrote:
> I don't quite understand your question, but I'll try to give a fuller
> explanation of the problem I was trying to solve to see if it perhaps
> answers your question.

I think the suggestion was something like this:

    -- | The @s@ type is an abstract "heap id" just like in 'ST'.
    type STSTM s a

    -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' etc.
    runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b

The idea being that, if the problem with catching
BlockedIndefinitelyOnSTM has to do with the fact that all STM
variables have global scope and so even if we could catch the
exception itself we'd still have problems with cleaning up the
collateral damage[1], then that's why it doesn't make sense to allow
BlockedIndefinitelyOnSTM to be caught. However, by using an abstract
heap-id we can bundle all related STSTM variables together, and we
know that once runSTSTM exits they can't be accessed from anywhere
else— so even if there's an error, we can still clean up all the
variables, threads, and other jetsam associated with this STSTM
computation.

[1] I don't know if this is actually the reason why why
BlockedIndefinitelyOnSTM is uncatchable, rather it sounded like this
is what Neil Davies was suggesting to be the reason. Also, I do seem
to recall something like this actually being the case; though it's
unclear whether the STSTM approach would actually be able to solve the
problem.

-- 
Live well,
~wren