black hole detection and concurrency
bertram.felgenhauer at googlemail.com
Mon Dec 29 11:07:22 EST 2008
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
As I wrote elsewhere in this thread, this should not be a problem
More information about the Glasgow-haskell-users