# ThreadPool hanging in DLLs
**URL:** https://discourse.itk.org/t/threadpool-hanging-in-dlls/426
**Category:** Engineering
**Created:** [November 15, 2017, 11:05pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426 "2017-11-15T23:05:04Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 15, 2017, 11:05pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426/1 "2017-11-15T23:05:04Z")
[Johan](https://github.com/vovythevov) discovered that ThreadPool causes the program to always hang on Windows if ITK is compiled as shared libraries. After trying to deal with it over the last few days, I created a MWE which does not depend on ITK and [entered](https://issues.itk.org/jira/browse/ITK-3575) it in the bug tracker.
Does somebody know of an elegant solution to this problem? The ugly one is in this proposed [patch](http://review.source.kitware.com/#/c/22797).
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [November 16, 2017, 1:55pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426/2 "2017-11-16T13:55:18Z")
There seems to be a lot of little changes in that proposed patch. Which are necessary to address the “race condition”?
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 16, 2017, 2:24pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426/3 "2017-11-16T14:24:24Z")
Changes in the [destructor](http://review.source.kitware.com/#/c/22797/1/Modules/Core/Common/src/itkThreadPool.cxx) are related to the bug workaround. The other changes are supposed to make threads [play better](https://stackoverflow.com/questions/331536/windows-threading-beginthread-vs-beginthreadex-vs-createthread-c) with MSVC CRT library, and be more consistent with threading [implementation](https://github.com/InsightSoftwareConsortium/ITK/blob/a27ab383cd6fa41a2c02f5913bf966261d492985/Modules/Core/Common/src/itkMultiThreaderWinThreads.cxx#L74-L84) in itkMultiThreader.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [November 16, 2017, 2:37pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426/4 "2017-11-16T14:37:09Z")
What about the approach that was used for the ObjectFactoryBase:
>
Would having a separate object which is deconstructed when the code is unloaded help?
Also keep in mind that issues when there are duplicate symbols in ITK:
>
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 16, 2017, 3:31pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426/5 "2017-11-16T15:31:44Z")
Great suggestion Brad! I will try that, probably next week.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 17, 2017, 11:23pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426/6 "2017-11-17T23:23:52Z")
I tried it and it doesn’t work. Here is my attempt:
```
static ThreadPool::Pointer m_ThreadPoolInstance;
namespace
{
class CleanUpThreadPool
{
public:
~CleanUpThreadPool()
{
m_ThreadPoolInstance = ITK_NULLPTR; // removing last reference invokes the destructor
}
};
//NOTE: KWStyle insists on m_ for m_CleanUpThreadPoolGlobal
static CleanUpThreadPool m_CleanUpThreadPoolGlobal;
}
```
The destructors of both CleanUpThreadPool and SmartPointer are called at DllMain `DLL_PROCESS_DETACH` time, so this doesn’t help. Because ITKCommon.dll is being detached due to process termination, [lpvReserved](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx) is non-NULL.
> When handling DLL\_PROCESS\_DETACH, a DLL should free resources such as heap memory only if the DLL is being unloaded dynamically (the lpReserved parameter is NULL). If the process is terminating (the lpvReserved parameter is non-NULL), all threads in the process except the current thread either have exited already or have been explicitly terminated by a call to the ExitProcess function, which might leave some process resources such as heaps in an inconsistent state. In this case, it is not safe for the DLL to clean up the resources. Instead, the DLL should allow the operating system to reclaim the memory.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [November 22, 2017, 7:52pm UTC](https://discourse.itk.org/t/threadpool-hanging-in-dlls/426/7 "2017-11-22T19:52:42Z")
Bug [3575](https://issues.itk.org/jira/browse/ITK-3575) has been fixed by this commit:
>