title: IO Completion Ports vs. Thread Pool API
body: <p>I had a problem described <a href="https://stackoverflow.com/questions/4258283/waiting-win32-threads">here</a>, and I was suggested to use IO completion ports or thread pool. </p>
  
  <p>I have implemented IO completion, calling <code>PostQueuedCompletionStatus</code> to enqueue the task and <code>GetQueuedCompletionStatus</code> to get the next task to execute it. I am using IO completion port as a multi-producer/multi-consumer thread-safe FIFO container without explicit locks. This makes me have full control over the threads, because I may need to terminate the ones process for a long time and report them. Also <code>GetQueuedCompletionStatus</code> waits the calling thread if there is no task left. </p>
  
  <p>Aside from the termination, thread pool suits my needs: my tasks are completed less than a millisecond, but there are lots of them. Also calling <code>QueueUserWorkItem</code> and letting the OS do the synchronizations and executions is simpler.</p>
  
  <p>Are there any differences between two approaches performance-wise? Any comments about my implementation?</p>