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 <[email protected]> wrote: > On Sat, Jul 19, 2014 at 11:24 PM, wren romano <[email protected]> > 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 > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
