I'm working on creating an async handler for ASP.NET that will execute a slow stored procedure. I think I understand that to gain additional throughput on a mixed load of slow and fast pages, the slow page needs to be executed on a thread pool separate from the one the ASP.NET uses, otherwise the async pattern will cause double the number of scarce threads to be used (correct me if I'm wrong).
So I have found System.Threading.ThreadPool - it looks like it should do the trick, but...
The various tutorials on the net such as this one which uses this custom pool, the one in John Skeet's MiscUtils, and the custom thread pool referenced in this tutorial about async patterns.
System.Threading.ThreadPool has existed since 1.1 - why do people routinely feel the need to write a brand new one? Should I avoid using System.Threading.ThreadPool?
I'm a rank beginner when it comes to threading, so go easy on the undefined jargon.
UPDATE. The stored procedure to be executed will not necessarily be MS-SQL and will not necessarily be able to use a built-in async method such as BeginExecuteNonQuery().
Here's what I found on the topic. Why you shouldn't use ThreadPool in ASP.NET http://madskristensen.net/post/Done28099t-use-the-ThreadPool-in-ASPNET.aspx. It's quite old but I don't think it has changed that much. Or correct me if I'm wrong.
Using the System.Threading.ThreadPool or a custom delegate and calling its BeginInvoke offer a quick way to fire off worker threads for your application. But unfortunately, they hurt the overall performance of your application since they consume threads from the same pool used by ASP.NET to handle HTTP requests.
Using custom threads with the aid of System.Threading.Thread class should solve the problem as the threads created are not part of your application's pool.