IHttpAsyncHandler表示异步运行请求。
使用线程池也可以异步运行。
因此，如果我想实现一个函数（比如Comet，long poll），在使用线程池和IHttpHandler之间使用IHttpAsyncHandler，哪个更好？
编辑： @Jon Skeet： 感谢您的耐心回复。让我来总结一下。如果我在IHttpHandler中使用delegate.BeginInvoke，处理请求的“主线程”仍然会一直旋转，直到请求结束，无论池化线程发生了什么。如果我使用IHttpAsyncHandler，处理请求的“主线程”将调用BeginProcessRequest，之后，它将被释放（处理其他请求）。 BeginProcessRequest方法将异步执行某些操作。当异步操作完成时，将调用EndProcessRequest方法。（或者我们可以说'主线程'将调用EndProcessRequest函数来完成当前请求）
以上都是我的想法，是不是？
答案 0 :(得分：3)
不同之处在于，使用真正的异步模型，您根本不需要每个请求一个线程。如果每个请求都有一个线程，无论它是否在线程池上，你都会陷入处理大量连接的困境（就像你需要长时间轮询一样）。
假设您有十万个客户端，每个长轮询 - 您真的想要100,000个线程吗？ （提示：我怀疑你有足够的记忆......）
使用真正的异步，您可以通过结束请求来响应事件，而每个请求都有一个专用线程。请注意，使用C＃5和.NET 4.5，还有比使用IHttpAsyncHandler更简单的方法。这取决于你想要实现的目标，但是WCF和MVC都有异步导向的方法，你可以使用await表达式等编写异步方法。如果你等待一些本身不需要的东西一个线程（例如一个计时器，或者可能是一些IO完成）然后你可以管理一个巨大的数量的并发连接。
编辑：要回答您的其他问题：是的，如果您只使用IHttpHandler，则ProcessRequest来电完成后，必须才能完成。你不能只是把它“悬挂”......而IHttpAsyncHandler允许请求仍在进行中，直到调用EndProcessRequest为止。不要忘记这是一个非常古老的界面 - 它没有非常明确的文档记录，我不建议使用它这些天，当有明显更好的异步方法，特别是使用.NET 4.5和C＃5。但是能够有一个正在进行的请求但没有任何特定线程与之关联的主要观点仍然存在。