Reputation: 3520
Final question for today :) thanks for your input on the previous ones. BTW: Already searched the forum on this and nothing quite answers this one.
We use some 3rd party libraries which pop work onto the Threadpool and we don't want to shutdown while there are outstanding activities.
When shutting down an application, the application will shutdown even if there is work outstanding in the System.Threading.ThreadPool because these threads are back ground threads.
Other than doing some form of reference counting (and enforcing every item Queued into the pool to use this mechanism, which we don't have control over) is there some way to stop the application shutting down while there is outstanding work to be done.
I've looked at using the GetAvailableThreads() vs GetMaxThreads(), but these can be the same because we may have caught the Threadpool as a thread was freed up but not allocated a queued workitem.
All help appreciated?
Kind Regards Noel
Upvotes: 1
Views: 290
Reputation: 3520
Thanks for your replies. I've found a work-around outside of the thread pool using AOP and Castle Windsors dynamic proxy to inject referencing counting around the class. Luckily for me the class exposed a clean interface that I could wrap and it works a treat.
Upvotes: 0
Reputation:
Since I'm real programmer (that's C, boys ;-) I've not used ThreadPool.
However, a suggestion comes to mind - have a semaphore increment on each task you issue into threadpool, and that that semaphore be released on completion.
When your app comes to exit, wait on the semaphore.
Any use?
Upvotes: 1
Reputation: 29345
I think Marc Gravell is right. Though if you could get access to the threads being used in the thread pool somehow then you could change the Thread.IsBackground property to false to achieve what you want. But I am not sure how you would obtain a reference to a managed thread within the thread pool.
Upvotes: 0
Reputation: 1062865
Unless you can get some kind of callback into the 3rd-party code (maybe a completion event), you are going to struggle to know when they have stopped using the ThreadPool
. Sorry. Such code should typically be on a non-background thread. I realise you don't have control over this - I'm just not sure that there is an easy way out of the hole, either.
Upvotes: 1