views:

197

answers:

1

OK, as I understand it, the .NET Threadpool maintains a number of background threads ready to be used for tasks of some kind.

The Get/SetMinThreads and Get/SetMaxThreads methods contain two parameters that can be returned or adjusted.

According to MSDN the two parameters indicate the number of worker threads and the number of threads used for async IO operations.

What type of operations use these specific type of thread?

Worker threads:

  1. QueueUserWorkItem I presume.
  2. Anything else?

Async IO threads:

  1. Used when calling Beginxxx, Endxxx on file streams for example? (Or network, serial port, etc.)
  2. Anything else?

Thanks for any clarification, or a good link on the subject.

+1  A: 

Yes, QUWI but also a delegate type's BeginInvoke() method. And employed by a few classes, BackgroundWorker is the best known example. Which under the hood merely uses delegate's BeginInvoke().

I/O completion threads are a very low-level Windows feature to get code to run quickly when an I/O request completes. Most visible from the ReadFileEx() function's last argument, there are others. The managed equivalent is exposed through ThreadPool.BindHandle().

It is the job of .NET classes to get that right. Just a few use it: FileStream, PipeStream, FileSystemWatcher, Socket, SerialPort's internal worker thread and some WCF channel support classes.

I'm personally not a big fan of getting these config details exposed in the API, especially the I/O completion thread ones. It's a bit of a cop-out by the BCL team, some FUD on their end. These settings affect the entire program, the defaults are already quite generous. Tinkering with them is roughly equivalent to calling GC.Collect(). If you ever manage to find a good reason to change them, that better be when stuck in a hellhole with only one hour left to catch the plane back home.

Hans Passant