This is a neat trick indeed! I'd appreciate an explanation of killing one's own thread and then continuing (with a restart in this case). How does the post-kill resumption occur? That is, how does control pass to the tail-recursive call after the self-kill?<br>
<br> - Conal<br><br><br><div class="gmail_quote">2008/12/28 Peter Verswyvelen <span dir="ltr"><<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I fail to understand this part of the code:<div class="Ih2E3d"><div><br></div><div> case fromException e of<br> Just ThreadKilled -> do<br> myThreadId >>= killThread<br><span style="font-weight: bold;"> unblock (race a b)<br>
</span></div><div><br></div></div><div>So the current thread gets killed synchronously, then then the race function is evaluated again? The latter I don't get.</div><div><div></div><div class="Wj3C7c"><div><br></div>
<div><br></div><div><br><div class="gmail_quote">
On Sun, Dec 28, 2008 at 3:03 AM, Bertram Felgenhauer <span dir="ltr"><<a href="mailto:bertram.felgenhauer@googlemail.com" target="_blank">bertram.felgenhauer@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Sterling Clover wrote:<br>
> On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote:<br>
</div><div>>> In the above code, there is a small window between catching the<br>
>> ThreadKilled exception and throwing it again though, where other<br>
>> exceptions may creep in. The only way I see of fixing that is to use<br>
>> 'block' and 'unblock' directly.<br>
><br>
> That certainly seems to do the trick for the simple example at least. One<br>
> way to reason about it better would be, instead of folding everything into<br>
> the race function, to simply modify ghc's bracket function to give us the<br>
> behavior we'd prefer (speaking of which, I recall there's something in the<br>
> works for 6.12 or so to improve rethrowing of asynchronous exceptions?)<br>
><br>
> brackAsync before after thing =<br>
> block (do<br>
> a <- before<br>
> r <- catch<br>
> (unblock (thing a))<br>
> (\_ -> after a >> myThreadId >>= killThread >><br>
> brackAsync before after thing )<br>
> after a<br>
> return r<br>
> )<br>
> where threadKilled ThreadKilled = Just ()<br>
> threadKilled _ = Nothing<br>
<br>
</div>This code turns any exception into ThreadKilled further down the stack.<br>
<br>
(\e -> do<br>
after a<br>
myThreadId >>= flip throwTo (e :: SomeException)<br>
...<br>
<br>
might do the trick.<br>
<br>
My assumption was that anything but 'ThreadKilled' would be a<br>
real error. This isn't really true, I guess - thanks to throwTo,<br>
any exception could be asynchronous.<br>
<br>
If an exception is thrown, 'after a' is run again after the computation<br>
has resumed.<br>
<br>
That's why I did the cleanup within the 'catch'.<br>
<br>
But there's no reason why you couldn't do that as well:<br>
<div><br>
brackAsync before after thing =<br>
block $ do<br>
a <- before<br>
</div> catch (unblock (thing a) >>= \r -> after a >> return r) $<br>
\e -> do<br>
after a<br>
myThreadId >>= flip throwTo (e :: SomeException)<br>
brackAsync before after thing )<br>
<div><br>
> This brackAsync just drops in to the previous code where bracket was and<br>
> appears to perform correctly.<br>
<br>
</div>Right. 'race' should also unblock exceptions in the worker threads,<br>
<br>
withThread u v = brackAsync (forkIO (unblock u)) killThread (const v)<br>
<br>
but that's an independent change.<br>
<div><br>
> Further, if we place a trace after the<br>
> killThread, we se it gets executed once when the example is read (i.e. a<br>
> resumption) but it does not get executed if the (`seq` v) is removed from<br>
> the example So this gives me some hope that this is actually doing what<br>
> we'd like. I don't doubt it may have further kinks however.<br>
<br>
</div>At least the GHC RTS has support for the hard part - unwinding the stack<br>
so that computations can be resumed seamlessly.<br>
<br>
I'm not sure which of the approaches I like better - it seems that we<br>
have a choice between turning async exceptions into sync ones or vice<br>
versa, and neither choice is strictly superior to the other.<br>
<br>
Enjoy,<br>
<br>
Bertram<br>
<br>
'race' update:<br>
- Bugfix: Previously, only AsyncException-s would be caught.<br>
Use 'fromException' to select the ThreadKilled exception.<br>
- I tried using a custom 'SuspendException' type, but this resulted in<br>
'test: SuspendException' messages on the console, while ThreadKilled<br>
is silently ignored... as documented:<br>
<a href="http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AforkIO" target="_blank">http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AforkIO</a><br>
(<a href="http://tinyurl.com/9t5pxs" target="_blank">http://tinyurl.com/9t5pxs</a>)<br>
- Tweak: Block exceptions while running 'cleanup' to avoid killing<br>
threads twice.<br>
- Trick: takeMVar is a blocking operation, so exceptions can be<br>
delivered while it's waiting - there's no need to use 'unblock' for<br>
this. In other words, unblock (takeMVar v) and takeMVar v are<br>
essentially equivalent for our purposes.<br>
<div><br>
race :: IO a -> IO a -> IO a<br>
</div>race a b = block $ do<br>
v <- newEmptyMVar<br>
let t x = unblock (x >>= putMVar v)<br>
ta <- forkIO (t a)<br>
tb <- forkIO (t b)<br>
let cleanup = killThread ta >> killThread tb<br>
(do r <- takeMVar v; cleanup; return r) `catch`<br>
\e -> cleanup >><br>
case fromException e of<br>
Just ThreadKilled -> do<br>
myThreadId >>= killThread<br>
unblock (race a b)<br>
_ -> throwIO e<br>
<div><div></div><div>_______________________________________________<br>
Reactive mailing list<br>
<a href="mailto:Reactive@haskell.org" target="_blank">Reactive@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/reactive" target="_blank">http://www.haskell.org/mailman/listinfo/reactive</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Reactive mailing list<br>
<a href="mailto:Reactive@haskell.org">Reactive@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/reactive" target="_blank">http://www.haskell.org/mailman/listinfo/reactive</a><br>
<br></blockquote></div><br>