On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote:
The key part here is 'myThreadId >>= killThread' which throws an
asynchronous exception to the thread itself, causing the update
frames to be saved on the heap.
Note that 'myThreadId >>= killThread' is not equivalent to
'throw ThreadKilled'; it is a synchronous exception and replaces
thunks
pointed to by the update frames by another call to the raise
primitive -
the result being that the exception gets rethrown whenever such a
thunk
is evaluated. This happens with 'finally' and 'bracket': they use
'throw' for re-throwing the exception.
See rts/RaiseAsync.c (raiseAsync() in particular) for the gory details
for the first case, and rts/Schedule.c, raiseExceptionHelper() for the
second case.
In the above code, there is a small window between catching the
ThreadKilled exception and throwing it again though, where other
exceptions may creep in. The only way I see of fixing that is to use
'block' and 'unblock' directly.
That certainly seems to do the trick for the simple example at least.
One way to reason about it better would be, instead of folding
everything into the race function, to simply modify ghc's bracket
function to give us the behavior we'd prefer (speaking of which, I
recall there's something in the works for 6.12 or so to improve
rethrowing of asynchronous exceptions?)
brackAsync before after thing =
block (do
a <- before
r <- catch
(unblock (thing a))
(\_ -> after a >> myThreadId >>= killThread >> brackAsync
before after thing )
after a
return r
)
where threadKilled ThreadKilled = Just ()
threadKilled _ = Nothing
This brackAsync just drops in to the previous code where bracket was
and appears to perform correctly. Further, if we place a trace after
the killThread, we se it gets executed once when the example is read
(i.e. a resumption) but it does not get executed if the (`seq` v) is
removed from the example So this gives me some hope that this is
actually doing what we'd like. I don't doubt it may have further
kinks however.
Cheers,
Sterl.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
