Timeout Pattern - How bad is Thread.Abort really?

Question

I've read at various websites that Thread.Abort is not very good to use. In this case, how do you implement a timeout pattern? For instance, I've read that MS uses the pattern below (which I've wrapped in an extension method) throughout the framework. Personally, I think this is a pretty cool extension, but I'm worried about the Thread.Abort. Does anyone have a better way?

 public static bool CallandWait(this Action action, int timeout)
    {
        Thread subThread = null;
        Action wrappedAction = () =>
        {
            subThread = Thread.CurrentThread;
            action();
        };

        IAsyncResult result = wrappedAction.BeginInvoke(null, null);

        if (((timeout != -1) && !result.IsCompleted) && (!result.AsyncWaitHandle.WaitOne(timeout, false) || !result.IsCompleted))
        {
            if (subThread != null)
            {
                subThread.Abort();
            }

            return false;
        }
        else
        {
            wrappedAction.EndInvoke(result);
            return true;
        }
    }

Answer 1

Basically you're talking about aborting an action which (as far as we know) has no graceful way of aborting.

That means there's going to be no safe way of aborting it. Thread.Abort is just not a nice thing to do - there are various race conditions and ugly situations you can get into (see the link in Richard's answer). I would try desperately hard to avoid wanting to cancel actions that don't know about cancellation - and if you absolutely have to do it, consider restarting the whole app afterwards, as you may no longer be in a sane state.

Answer 2

Potentially very bad.

The aborted thread could leave shared state corrupted, could leave asynchronous operations running, ...

See Joe Duffy's blog: "Managed code and asynchronous exception hardening".