Avoiding BlockedIndefinitelyOnSTM exceptions

Neil Davies semanticphilosopher at gmail.com
Sun Jul 20 08:45:44 UTC 2014


Wren

That is sort of idea I was alluding to - there is a communication scope, the set
of things that now need be cleaned up. 

In designing systems I'm always aggregating scope of failures to create 
“units of redundancy” and handling / recovering (and making sure failure 
within that scope becomes “total”) - reduces the complexity of reasoning
about fault modes.


Neil

On 20 Jul 2014, at 04:48, wren romano <winterkoninkje at gmail.com> wrote:

> On Sat, Jul 19, 2014 at 11:24 PM, wren romano <winterkoninkje at gmail.com> wrote:
>>    -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' etc.
>>    runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b
> 
> That should've been something more sensible, like:
> 
>    atomicallySTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> IO
> (Either a 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.
>> 
>> [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.
> 
> Fwiw, after (re)reading ezyang's blog post about
> BlockedIndefinitelyOnSTM, it seems clear that this is not actually
> what the problem is. Though he also mentioned that the exact details
> of BlockedIndefinitelyOnSTM shouldn't be relied upon, since the
> exception is just a trick to kill off useless threads in order to
> collect more garbage.
> 
> ...
> 
> In terms of solving your actual problem in pipes, it seems like what
> you really want are weak-references for STM. That way you don't rely
> on the behavior of BlockedIndefinitelyOnSTM, and you can still get
> garbage collection to send you signals whenever something becomes
> inaccessible, allowing you to handle things however you like. Seems
> like it shouldn't be too hard to do, since weak-references for IO are
> already supported; though, of course, it'll still take a fair deal of
> hacking to implement it.
> 
> -- 
> Live well,
> ~wren
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



More information about the Glasgow-haskell-users mailing list