https://svn.boost.org/trac10/ticket/12731 <p> I just hit a deadlock while <code>join()</code>ing a <code>boost::thread</code>, meaning the <code>join()</code> is blocked for ever. I did this by <code>pthread_cancel()</code>ing the thread (using <code>native_handle()</code>) and then waiting for it to actually terminate using <code>join()</code>. </p> <p> See the attached minimal case. </p> <p> Boost's <code>join()</code> never returns, while <code>pthread_join(native_handle())</code> works as expected. Looking at the code here <a class="ext-link" href="https://github.com/boostorg/thread/blob/develop/src/pthread/thread.cpp"><span class="icon">​</span>https://github.com/boostorg/thread/blob/develop/src/pthread/thread.cpp</a> I notice that <code>join_noexcept()</code> actually waits on condition variables before calling <code>pthread_join</code>. </p> <p> I believe this is a design flaw, as there are many dirty/low-level ways to stop a thread (e.g. signals or OS threading API), and there is no way to keep the <code>boost::thread</code> state in sync with the thread state in these cases of non-standard termination. </p> <p> I think we should be only relying on the OS API here, to query the thread state (running, joinable, etc.) instead of storing flags that may run out of sync. Alternatively, the documentation should be updated with a prominent warning saying that <code>boost::thread</code> has undefined behavior if a thread is stopped in a non standard way and <code>native_handle</code> should be used with care. </p> <p> Note that at least libstdc++ does not exbibit the same problem. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12731 Trac 1.4.3 Antoine Poliakov <antoinep92@…> Fri, 06 Jan 2017 14:54:51 GMT https://svn.boost.org/trac10/ticket/12731 https://svn.boost.org/trac10/ticket/12731 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">main.cpp</span> </li> </ul> <p> minimal test case to reproduce (unix only!) </p> Ticket viboes Sun, 29 Jan 2017 16:31:34 GMT https://svn.boost.org/trac10/ticket/12731#comment:1 https://svn.boost.org/trac10/ticket/12731#comment:1 <ul> <li><strong>owner</strong> changed from <span class="trac-author">Anthony Williams</span> to <span class="trac-author">viboes</span> </li> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">assigned</span> </li> </ul> <p> As I understand the code, waiting on condition variables is a consequence of the interruptible nature to boost thread. </p> <p> Could you tell us where the thread is blocked? </p> <p> Any suggestion of for improving the code is welcome. </p> <p> I believe that waiting for a fix, updating the documentation is a good thing to do. Please create a specific ticket for the documentation. A patch is welcome also here. </p> Ticket viboes Sun, 19 Feb 2017 11:00:09 GMT https://svn.boost.org/trac10/ticket/12731#comment:2 https://svn.boost.org/trac10/ticket/12731#comment:2 <ul> <li><strong>type</strong> <span class="trac-field-old">Bugs</span> → <span class="trac-field-new">Support Requests</span> </li> </ul> <p> Moved to Support request waiting for more information </p> Ticket viboes Tue, 14 Nov 2017 20:49:25 GMT https://svn.boost.org/trac10/ticket/12731#comment:3 https://svn.boost.org/trac10/ticket/12731#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">assigned</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">obsolete</span> </li> </ul> <p> Closed as there is no follow up. </p> Ticket