black hole detection and concurrency

[Sterling Clover]

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.