WorkScheduler should use a dedicated ThreadPool of test execution threads

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Create 20-50+ Parallelizable tests that allocate (and reuse) ThreadStatic 
resources. I used 69 Rows of a single data-driven test.
2.Run the tests using a fairly small DegreeOfParallelism (e.g. 2-4).

What is the expected output? What do you see instead?

Notice that the total number of ThreadStatic resource instances allocated 
during the test run is far greater than the DegreeOfParallelism. This is 
because the default .NET ThreadPool contains 25+ Threads, and makes no attempt 
to maximize reuse of the same Threads, resulting in far more resources getting 
allocated than are really needed to meet the requirements of the 
DegreeOfParallelism.

This scenario is very applicable when many tests need to access to 
thread-unsafe resources that are expensive to allocate or initialize. 
Especially if the resources are usable only in the Thread that they were 
originally created, such as COM objects like the ShDocVw in Microsoft's IE 
automation API (which is also used in internally by Watin).

Please use labels and text to provide additional information.

I have attached a patch file showing one possible fix for this problem using 
the "SmartThreadPool" project. If there are reasons that prevent the use of the 
SmartThreadPool, the patch can be used as an example of how a different custom 
ThreadPool (that should allow the MaxThreadCount to be configured per pool) 
could be similarly integrated.

NOTE: I had to modify the STP project slightly so that it was signed with a 
strong key in order to use it in the Gallio source. I didn't include the DLL or 
the project file changes for the Assembly References, but contact me if these 
are needed and I can provide them.

Original issue reported on code.google.com by justin.w...@gmail.com on 23 Aug 2010 at 5:56

Attachments:

• WorkScheduler.DedicatedThreadPool.patch

[GoogleCodeExporter]

Also note that the patch code was written in a way that would make it easy to 
make the use of a dedicated thread pool into a configurable option. If this 
flexibility wasn't needed, then the bool const that is acting as a placeholder 
for a configuration setting could be removed, and the code that references it 
could be simplified slightly.

Original comment by justin.w...@gmail.com on 23 Aug 2010 at 6:00