Re: Safely implementing Thread.Abort

Rhys Weatherley wrote:
> The JIT case is easy.  It can be done with signals: send a signal to the 
> thread and just throw from within the handler (which Mono does BTW).  It will 

I did think of that.  But it looked like a bug waiting to
happen.  You could do the same with CVM, even now.  The
implementation I was thinking about just did a longjmp
back to the interpreter.  But there seemed to be zillions
of places in the interpreter that would leave things in
an inconsistent state if you just lept out of them without
warning.

And that assumes your signal() handler checked you were
in the interpreter to start with, so it wouldn't leap out
of some critical piece of code such as the GC.

> 3. Don't change the method cache.  The method cache is read-only on purpose.

That reduces the options considerably, which is a good
thing.

> If worst comes to worst, it isn't impossible to add a "--disable-aborts" 
> option to "ilrun" that removes the overhead for people who don't want it.

If we are prepared to do that, then another trade off
becomes possible.  All we are trying to solve here is
the "for (;;) continue" case.  I presume that is a
fairly uncommon case.  If we are prepared to assume
that an aborted thread will at some stage do an
expensive operation, such as:
   (a) Block on a WaitHandle, or
   (b) Return from a function call, or
   (c) Process an exception
Then we can just check at those places.  As they are
expensive the overhead of an extra if() won't matter
much.

I am not sure if a function return would be expensive
under the JIT, but that is the JIT authors problem.
By all reports he is a very capable man.

If people want to break "for (;;) continue;", then pass
ilrun the "--enable-aborts" flag.