chadmyers :
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.\n\nI/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.\n\nWindows 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.\n\nWorker 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.\n\n[Edit]: I also found this link which is particularly relevant to this question:\nhttp://blogs.msdn.com/ericeil/archive/2008/06/20/windows-i-o-threads-vs-managed-i-o-threads.aspx",
2008-09-26T02:35:57