<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 20, 2014 at 5:48 AM, wren romano <span dir="ltr"><<a href="mailto:winterkoninkje@gmail.com" target="_blank">winterkoninkje@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Sat, Jul 19, 2014 at 11:24 PM, wren romano <<a href="mailto:winterkoninkje@gmail.com">winterkoninkje@gmail.com</a>> wrote:<br>

>     -- | The second argument allows handling 'BlockedIndefinitelyOnSTM' etc.<br>
>     runSTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> b<br>
<br>
</div>That should've been something more sensible, like:<br>
<br>
    atomicallySTSTM :: (forall s. STSTM s a) -> (STMError -> b) -> IO<br>
(Either a b)<br></blockquote><div><br></div><div>Wouldn't combining it wih ST defeat the purpose of STM? The purpose of STM being to synchronize access to shared variables using atomic transactions. If all the variables in  your atomic transaction are guaranteed to be local and not touched by any other transaction, which I believe the above type says, then you don't need a transaction at all.<br>
<br></div><div>Or was the idea to create some kind of outer scope within which individual atomic (sub)transactions may share access to variables, but not without?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
> The idea being that, if the problem with catching<br>
> BlockedIndefinitelyOnSTM has to do with the fact that all STM<br>
> variables have global scope and so even if we could catch the<br>
> exception itself we'd still have problems with cleaning up the<br>
> collateral damage[1], then that's why it doesn't make sense to allow<br>
> BlockedIndefinitelyOnSTM to be caught.<br>
><br>
</div><div class="">> [1] I don't know if this is actually the reason why why<br>
> BlockedIndefinitelyOnSTM is uncatchable, rather it sounded like this<br>
> is what Neil Davies was suggesting to be the reason. Also, I do seem<br>
> to recall something like this actually being the case; though it's<br>
> unclear whether the STSTM approach would actually be able to solve the<br>
> problem.<br>
<br>
</div>Fwiw, after (re)reading ezyang's blog post about<br>
BlockedIndefinitelyOnSTM, it seems clear that this is not actually<br>
what the problem is. Though he also mentioned that the exact details<br>
of BlockedIndefinitelyOnSTM shouldn't be relied upon, since the<br>
exception is just a trick to kill off useless threads in order to<br>
collect more garbage.<br>
<br>
...<br>
<br>
In terms of solving your actual problem in pipes, it seems like what<br>
you really want are weak-references for STM. That way you don't rely<br>
on the behavior of BlockedIndefinitelyOnSTM, and you can still get<br>
garbage collection to send you signals whenever something becomes<br>
inaccessible, allowing you to handle things however you like. Seems<br>
like it shouldn't be too hard to do, since weak-references for IO are<br>
already supported; though, of course, it'll still take a fair deal of<br>
hacking to implement it.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Live well,<br>
~wren<br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</div></div></blockquote></div><br></div></div>