[Mono-devel-list] Anyone have ideas on making ThreadAbor

[Varga Zoltan]

                                                 Hi,

   I would advocate using the polling approach to handling async
exceptions like ThreadAbort. The current approach has many
problems:
- since the runtime can be in any state when receiving the
signal,
  the handler can only call code which is 'async-signal
safe'. This is
  impossible to satisfy in general, since during exception
handling,
  filter code can be called which might execute arbitary
code. Also, 
  common code like the Boehm GC allocation functions are not
async
  safe.
- locking problems. If the thread holds unmanaged locks and
it is 
  aborted, the locks are not released, leading to a deadlock
later. This
  is already happening during appdomain unloading. This could be
  solved by somehow registering which thread holds which
lock, but
  I think this is hard to implement and slow. Also, some
locks, like the
  GC lock, are outside our control and can't be handled that
way.
- Disabling signals is another solution but it is also hard
to get right,
  and would hurt performance.
- It doesn't work on Windows, and don't seem to work on
Solaris either.

I think polling can be implemented efficiently:
- If the thread is in managed code when receiving the
signal, there is
   no problem, and the current approach can be used.
- If the thread is in unmanaged code, then a flag could be
set which is
   checked when returning from unmanaged code. Checking the flag
   can be done in one instruction by writing to a memory
location which
   is write protected by runtime when there is a pending
async exception
   for the thread/process. Since there is already some
overhead with
   managed->unmanaged transitions, this wouldn't hurt
performance much.

The other problem with polling is what happens if the thread
blocks
indefinitely in unmanaged code. There are two cases here:
- runtime code which is under our control: this code should
be written
   in such a way that it does not block indefinitely, e.g.
by checking 
  the return value of system calls, and if it is EINTR, then
check for async
  exceptions, and if there is an exception, then return from
the 
  native code, and the managed->unmanaged transition code
will do
   the rest.
- native code which is outside of our control like pinvoke:
There's little
   that can be done here. If the thread does not return to
managed 
   code, then it can't be aborted.

So this approach has the disadvantage that it doesn't always
work, i.e.
some threads can't be aborted. But it is much safer than the
current
approach, i.e. it doesn't lead to deadlocks and crashes.

                                                          
Zoltan










  


























> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com
> [mailto:mono-devel-list-admin at lists.ximian.com]On Behalf
Of ext Bernie
> Solomon
> Sent: Monday, April 12, 2004 6:57 PM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-devel-list] Anyone have ideas on making
> ThreadAbortException robust
> 
> 
> 
> 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.