black hole detection and concurrency

[Bertram Felgenhauer]

Simon Peyton-Jones wrote:
> | I have a good theory on the latter symptom (the "thread killed"
> | message). Sticking in some traces, as in my appended code, helped me
> | to see what's going on. It seems to be exactly what you describe --
> | the variable v is permanently bound to the exception it "evaluates"
> | to.  Since the right hand True portion of the unamb evaluates more
> | quickly, the spawned threads are killed and the left hand (the v)
> | "evaluates" to "thread killed".
> 
> This is odd (to me).  The "permanently bound" stuff applies only to
> *synchronous* exceptions, which thread-killing is not.  Simon M will
> have more to say when he gets back

This is true when the exception is raised the first time. However, some
exception handling functions like 'bracket' catch the exception, do
their cleanup, and then throw the exception again. This is done in
onException, and goes through throwIO and eventually raiseIO#. At this
point the originally asynchronous exception has become a synchronous
one.

As I wrote elsewhere in this thread, this should not be a problem
without unsafePerformIO.

Bertram