title: Why does a thread pool create a lot of unique threads?
body: <p>A COM application based on the 'free' threading model subscribes to events published from another COM application that runs out of process.</p>
  
  <p>The application works normally. But in some cases (or configurations?) it burns through a lot of so called <code>Tpp</code> worker threads.</p>
  
  <p>These threads apparently belong to a thread pool managed by Windows/COM. And they are at least used by COM to deliver incoming events to the application.</p>
  
  <p>When the application receives events, that always happens in the context of one of these worker threads.</p>
  
  <p>In the normal situation, updates are coming in from at most 2 or 3 unique worker threads.</p>
  
  <p>But in the abnormal situation the application sees new &amp; unique worker thread IDs appear every 3-8 minutes. Over the course of a week the application has seen about 1000 unique threads (!).</p>
  
  <p>I highly suspect there is something wrong here. Because surely the thread pool doesn't need so many different threads, right?</p>
  
  <p>What could be a reason for the thread pool behavior I'm seeing. Is it just normal that it creates different threads from time to time? Are the old threads still sticking around doing nothing? What action could trigger this while the application is running in the context of the worker thread? </p>
  
  <p>Notes:</p>
  
  <ul>
  <li>Our application is an OPC DA client (and the other application is the Siemens OPC-DA server)</li>
  <li>The OS is Windows 10</li>
  <li>I do not yet know if the worker threads have exited or that they stick around doing nothing</li>
  </ul>
  
  <p>By way of an experiment I have tried several bad/illegal things to see if it is possible for our application to somehow break a worker thread
  - which would then explain why the thread pool would have to create a new one - we might have destroyed the old one. But that seems more difficult than I had expected:</p>
  
  <p>When running in the context of the worker thread, I have tried...</p>
  
  <ul>
  <li>deliberately hanging with <code>while (true) {}</code>, result: event delivery process just stalls, no new worker thread is being created for us though</li>
  <li>the deliberate uncaught c++ exception, no new worker thread is created</li>
  <li>triggering a deliberate (read) access violation, no new thread either...</li>
  </ul>
  
  <p>And that got me thinking, if our application can't kill that worker thread in an obvious way, what else could or why would the thread pool behave like this?</p>