What's the difference between a worker thread and an I/O thread?

Question

Looking at the processmodel element in the Web.Config there are two attributes.

maxWorkerThreads=\"25\" 
maxIoThreads=\"25\"

What is the di

Answer 1

Fundamentally not a lot, it's all about how ASP.NET and IIS allocate I/O wait objects and manage the contention and latency of communicating over the network and transferring data.

I/O threads are set aside as such because they will be doing I/O (as the name implies) and may have to wait for "long" periods of time (hundreds of milliseconds). They also can be optimized and used differently to take advantage of I/O completion port functionality in the Windows kernel. A single I/O thread may be managing multiple completion ports to maintain throughput.

Windows has a lot of capabilities for dealing with I/O blocking whereas ASP.NET/.NET has a plain concept of "Thread". ASP.NET can optimize for I/O by using more of the unmanaged threading capabilities in the OS. You wouldn't want to do this all the time for every thread as you lose a lot of capabilities that .NET gives you which is why there is a distinction between how the threads are intended to be used.

Worker threads are threads upon which regular "work" or just plain code/processing happens. Worker threads are unlikely to block a lot or wait on anything and will be short running and therefore require more aggressive scheduling to maximize processing power and throughput.

[Edit]: I also found this link which is particularly relevant to this question: http://blogs.msdn.com/ericeil/archive/2008/06/20/windows-i-o-threads-vs-managed-i-o-threads.aspx

Answer 2

Just to add on to chadmyers... Seems like I/O Threads was the old way ASP.NET serviced requests,

"Requests in IIS 5.0 are typically serviced over I/O threads, or threads performing asynchronous I/O because requests are dispatched to the worker process using asynchronous writes to a named pipe."

with IIS6.0 this has changed.

"Thus all requests are now serviced by worker threads drawn from the CLR thread pool and never on I/O threads."

Source: http://msdn.microsoft.com/hi-in/magazine/cc164128(en-us).aspx