Are there any non-obvious dangers in using threads in ASP.NET?

Question

This is something of a sibling question to this programmers question.

Briefly, we're looking at pushing some work that's been piggy-backing on user requests into the background "properly." The linked question has given me plenty of ideas should we go the service route, but hasn't really provided any convincing arguments as to why, exactly, we should.

I will admit that, to me, the ability to do the moral equivalent of

WorkQueue.Push(delegate(object context) { ... });

is really compelling, so if its just a little difficult (rather than inherently unworkable) I'm inclined to go with the background thread approach.

So, the problems with background threads I'm aware of (in the context of an AppPool):

• They can die at any time due to the AppPool being recycled
  • Solution: track when a task is being executed, so it can be re-run* should a new thread be needed
• The ThreadPool is used to respond to incoming HTTP queries, so using it can starve IIS
  • Solution: build our own thread pool, capping the number of threads as well.

My question is, what am I missing, if anything? What else can go wrongǂ with background threads in ASP.NET?

_{* The task in questions are already safe to re-run, so this isn't a problem.
ǂ Assume we're not doing anything really dumb, like throwing exceptions in background threads.}

Answer 1

I would stay away from launching threads from with-in your IIS AppDomain for StackOverflow. I don't have any hard evidence to support what I am going to say, but working with IIS for 10 years, I know that it works best when it is the only game in town.

There is also an alternative, I know this is going to be sort of a take off on my answer over on the programmers thread. But as I understand it you already have a solution that works by piggy-backing the work on user requests. Why not use that code, but only launch it when a special internal API is called. Then use Task Scheduler to call a CURL command that calls that API every 30 seconds or so to launch the tasks. This way you are letting IIS handle the threading and your code is handling something that it already does easily.