[Mono-devel-list] Anyone have ideas on making ThreadAbortException robust

Bernie Solomon bernard at ugsolutions.com
Mon Apr 12 12:56:55 EDT 2004

In running various tests I believe handling ThreadAbortException
isn't robust at present. Unless there is something going
on I haven't realized and hopefully someone will correct me.

This seems to be because there is nothing that knows
whether interrupting the current thread is globally safe at any
given instance. In particular when that thread owns one of the
global locks in the runtime. The first one I found was the
one for serializing calls to the handle daemon but the problem
seems more widespread. If the signal occurs while the lock
is taken it will never get unlocked and everything locks up. 

The two choices seem to be either to work out where to
disable handling this abort (by use of pthread_sigmask) or
where to actively enable it (have the signal handler just set
a flag which is tested in various spots). Disabling in various spots
means finding those cases - and coming up with a technique
for handling this which requires a little thought. If the order


if the thread blocks it will have signals blocked and not respond to 
aborts as it probably should. If the order is:


then if the signal arrives between the two calls we end up not
freeing the lock unless the signal handling mechanism knows
which global locks the current thread owns so perhaps the
signal handler can unlock them before throwing the exception.
This would require making global locks (at least) special
so they can be tidied up in the signal handling - and use of
the simulated CriticalSection api would require modifying.

Polling for abort has the standard sorts of problems with polling
(this would probably be easier in the interpreter) of performance
and not responding if something doesn't poll.

Anyone else have any comments on this?

Bernie Solomon

More information about the Mono-devel-list mailing list