The difference is that with a truly asynchronous model, you don't need a thread per request at all. If you have a thread per request, whether or not it's on the thread pool, you'll be stuck handling a large number of connections (as you need to for things like long polling).
Suppose you have a hundred thousand clients, each long-polling - do you really want 100,000 threads? (Hint: I doubt that you've got enough memory...)
With genuine asynchrony, you can react to events by ending a request without having a dedicated thread per request. Note that with C# 5 and .NET 4.5, there are simpler ways than using IHttpAsyncHandler
, too. It depends on what you're trying to achieve, but both WCF and MVC have async-oriented approaches where you can write an async method, using await
expressions etc. If you then await something which doesn't in itself take a thread (e.g. a timer, or perhaps some IO completing) then you can manage a huge number of concurrent connections.
EDIT: To respond to your further questions: yes, if you use just IHttpHandler
, the request must be completed when the ProcessRequest
call completes. You can't just leave it "dangling"... whereas IHttpAsyncHandler
allows the request to still be in progress until EndProcessRequest
is called. Don't forget that this is a very old interface though - it's not terribly clearly documented, and I wouldn't suggest using it these days, when there are significantly better approaches to asynchrony, particularly using .NET 4.5 and C# 5. But the main point of being able to have a request in progress but without any specific thread being associated with it still holds.