This project is read-only.

Nice work, when to use or not to use

Sep 23, 2009 at 7:54 PM

Nice job!

I have an application that needs to run multiple threads. One time the app might need to run 5 threads another time it might be 30 - it just depends. Each of those threads will have run times which vary - some may complete in a minute or less while others may run for 15 minutes or more. Would you recommend using your Smart Thread Pool or another method for controlling those threads?

Thanks, Butch

Sep 24, 2009 at 12:15 PM

Hi Butch,

The STP can be instantiated so you can create  several thread pool, one for each purpose.

This way long time work items will not interfere we short time work items.



Sep 24, 2009 at 12:35 PM


Thanks for the reply. I was thinking along those lines but thought I'd ask. Again, nice job!

Thanks, Butch

Sep 24, 2009 at 1:12 PM


One more question.

The threads my application will be running will be using com based objects. Do I need to do anything special besides including the interop for the com object that will be run by the thread?



Sep 24, 2009 at 6:59 PM


COM objects are sensitive to Apartments.

Make sure the threads in the thread pool are set to the correct apartment (STA/MTA).





Feb 3, 2010 at 8:52 PM


Do you have an example in the source code on how to run a thread in STA (for running COM objects)?

Thanks, jo

Feb 4, 2010 at 9:21 PM


I always thought that a thread gets it's apartment (STA/MTA) when it first call to a COM object, but I got it wrong.

Every thread starts by default as MTA, unless you state otherwise before it starts.

I assumed a call on SmartThreadPool.OnThreadInitialization is enough, but it is too late at this point, because the thread is already started.

To implement this correctly I need to add a field in the STPStartInfo that can set the value before the thread starts.



Feb 7, 2010 at 1:45 PM

That's right, you need another initialization field for setting the appartment state.

I have another interesting COM issue: sometimes my COM object in the worker thread throws a specific exception which makes the COM object corrupt. The only solution for the COM stuff the work again is to start it up again in a new thread and have the first thread killed. 

I've added an 'ExceptionEvaluator' to the SmartThreadPool class (type of Func<Exception, bool>) that evaluates the worker-exception and if true, it flags that specific worker-thread to be shutdown. This all happens in the ProcessQueuedItems() method. Seems to be working now but I'll give it some more tests.