How can I limit how long a task runs under .Net?

Question

I know there are various ways to limit how long a task runs under .Net and I wondered if there are any others I've missed or modifications/improvements to the methods I've used previously.

Where I am unclear on how exactly a methodology functions I have included questions on it.

Existing methods I'm aware of though not necessarily used myself:

1. Create a Thread, poll for it to finish for a certain time then kill the thread. This solution is not great as it relies on ThreadAbortException's which are somewhat nasty and if I remember you have no guarantee where you'll code will exit i.e. it may leave unamanged resources in use etc.
2. Use the IAsyncResult pattern, the problem with this is that you can wait for a certain amount of time but there isn't a simple way to signal that you want the request to be aborted so you have to rely on setting a boolean flag (or similar) which is checked for inside the async code and causes it to halt. Issue here is that if the async code is stuck in a certain section of the code it may continue to run for some time before it actually terminates.
3. I've often seen people recommend BackgroundWorker for async stuff but can you use this under ASP.Net (I'd assume so) and does it have a simple way of terminating the async process after a certain time?
4. Use the Task API in .Net 4.0 (currently all my work is constrained to .Net 3.5 so not an option for me). From a quick read of the MSDN documentation it looks like you can easily cancel a Task using the CancellationToken but how quickly does a cancellation take affect and does it ensure any finally blocks get called.

All solutions/suggestions/methodologies welcome

Answer 1

The cancellation token from 4 and the boolean flag from 2 are the same kind of mechanism. In both cases the task has to cooperate and check the flag regularly. The advantage of 4 is that you have a standardized flag instead of creating your own.

Aborting threads is evil, but manageable if your code is written carefully. In particular it's easy to corrupt global state.

The safe version of aborting a thread is running it in a different app-domain. Then you unload the app-domain once the thread has been killed. This will work in a safe way if all your unmanaged resources have correct critical finalizers/use SafeHandles.

Answer 2

The safest form of cancellation is always cooperative.

I recommend never killing a thread (via ThreadAbortException). If you absolutely have no choice, then make that code a separate process instead, which can be cleanly killed. AppDomains were a nice idea, but they don't hold up to the real world.

IAsyncResult, BackgroundWorker, and CancellationToken are all forms of cooperative cancellation. So they are all very clean (not losing resources, calling finally blocks, ...), but have the disadvantage that they can't handle "rogue" code.

If you are writing the background task code, then just use BackgroundWorker or CancellationToken. If you must work with possibly "rogue" code, then wrap it in a separate process.

BackgroundWorker will work just fine in ASP.NET, and it supports cooperative cancellation.