Steven Watanabe &lt;watanabesj@gmail.com&gt; wrote:<br /><br /><br />
<blockquote style="font-size: 12px; padding-left: 1em; margin-left: 1em; margin-bottom: 0px; border-left: #ccc 2px solid;">You have a race condition in your destructor.<br />pthread_cancel, does *not* wait for the thread<br />to terminate. You need to join the threads<br />before the queue is destroyed.</blockquote>
<br />It's funny and actualy quite often - while I was writing response to this quotation I found a bug, thank you! So I was about to write: "The race is only between cancellation point after sem_wait() call and manager-&gt;m_results.pop() in WorkerThreadManager::WorkerThread(), and my example uses sleep to be "sure" that WorkerThreadManager destruction occurs when A::Fun() is during sleep, so there is no access to queue". And the bug is trivial: I do pop() on an empty queue, I inteded to do it on m_tasks instead of m_results...<br />
 <br />
But why this bug caused crash when queue was being destructed?<br />
 <br />
Before I fixed this bug I also tried joining threads after cancellation, but it caused pthread_join to hang on a thread that was during task execution. Why did it happen? I use deferred cancellation so thread should be gently cancelled on sleep() which is a cancellation point.<br />
 <br />
Regards<br />
Marcin Adamski<br />