Access to old blogs

By default, old blogs are truncated from this web site.  If you want to read old entries that have scrolled off, go to the CATEGORIES section at the right hand side of the web page.  Select CLR (rss) and you’ll see the full list.

Comments (3)

  1. David Levine says:

    Hi Chris,

    I wanted to thank you for your blog – easily one of the best and most informative I’ve seen.

    There’s a question you might be able to shed some light on for me. It has to do with raising a ThreadAbort exception and terminating threads.

    Are Aborts raised in a synchronous manner so that it must be in a wait state (alertable or otherwise) or can it interrupt running code? For example, if the code were in a tight for-loop, could another thread issue an abort and actually interrupt the other thread? (side question: If it can actually interrupt it what mechanism is used to inject/raise the abort in the execution stream?)

    Also, you mentioned that TerminateThread should never be used. I agree in general, but how then does one handle the case of stopping a runaway thread? (This ties back to the other question about when an abort is seen). The scenario I have in mind is of a control engine executing user-defined code that is less-trusted then the execution engine – if the code is malicious or poorly written it would be desirable to be able to shut it down.

    Thanks, and I hope you are enjoying the nice holiday weather.


  2. Chris Brumme says:

    Dave, (are you the David Levine I worked with at Borland & Oracle?)

    If you abort your own thread via something like Thread.CurrentThread.Abort(), then the exception is raised synchronously. If you abort another thread, it is raised asynchronously. If that thread is in a managed blocking operation, we break it out of the wait state. If it is executing unmanaged code, we must wait for it to return to managed code before we can safely take control of it. But if it is executing managed code, we will take control of it under any circumstances. Even if the thread is executing "while (true) continue;" which is JITted to a single machine instruction like "label: JMP label" we can take control. Conceptually, this is like taking control of the thread so that a garbage collection can proceed. In fact, our current mechanism is slightly different from this. On X86, we can take control for a ThreadAbort on any JITted machine instruction except (I think) the prolog or epilog of a method. In the future, we’re likely to change the precise rules so that we can get more commonality with garbage collection and so that we can enable more compiler optimizations in the presence of exceptions.

    So you can use Thread.Abort to take control of a runaway thread in managed code. If you granted a thread UnmanagedCodePermission or a similar permission, it better not be runaway. You cannot safely take control of a thread that is executing unmanaged code on the Windows operating system — unless you are willing to terminate the process.