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

[Bernie Solomon]

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
was

        pthread_sigmask
        pthread_mutex_lock

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

        pthread_mutex_lock
        pthread_sigmask

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