Hacker News Reader

Comment by mythz | Hacker News Reader

The IHttpAsyncHandler doesn't work the same as the non-blocking event loops in Unix which only uses a single process for all requests. We actually didn't fare to well ourselves and had a poor experience trying to debug them in IIS, in the end we moved to a bespoke windows service to service our comet requests.

But you're right it should be included - care to contribute a piece on the topic?

View on HN

True, you won't get a single thread. You'll get a Threadpool. But we did like the flexibility of the Threadpool for things that had to be done synchronously or were not worth optimizing. It also allowed apps to take advantage of all CPU cores without extra configuration. With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want).

> With the new IIS you have a lot more control over the threading context (you can even run things straight on your IOCP thread if you want).

I am curious about this, can you provide a link or reference with more information?

http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thr...

"... If you’re curious to see how much faster ASP.NET requests execute without the thread switch, you can set the value to 0. This will cause the request to execute on the IIS I/O thread, without switching to a CLR Threadpool thread. ..."

Of course you would only ever set this if you are really doing every bit of I/O asynchronously in your application. Otherwise bad, bad things would happen (deadlock under load).

Reply on news.ycombinator.com