TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

How to stop Linux threads cleanly

61 点作者 r4um超过 1 年前

5 条评论

denotational超过 1 年前
&gt; Well, since thread cancellation is implemented using exceptions, and thread cancellation can happen in arbitrary places, we’re always liable to a cancellation happening in a noexcept block, which is undefined behavior, and which in practice will cause your program to crash.<p>I believe the author is mistaken here: throwing an exception that reaches the end of a noexcept block is <i>not</i> undefined behaviour; it will call std::terminate per [except.spec] [1].<p>The linked mailing list post [2] makes no mention of UB, only that this might cause exceptions to be thrown unbeknownst to the programmer in implicitly-noexcept blocks (i.e. destructors) which now might need a noexcept(false) to avoid std::terminate (although that’s still not great because throwing from a destructor will likely lead to resource leaks even if it’s handled).<p>[1] <a href="https:&#x2F;&#x2F;timsong-cpp.github.io&#x2F;cppwp&#x2F;n4868&#x2F;except.spec#5" rel="nofollow">https:&#x2F;&#x2F;timsong-cpp.github.io&#x2F;cppwp&#x2F;n4868&#x2F;except.spec#5</a><p>[2] <a href="https:&#x2F;&#x2F;gcc.gnu.org&#x2F;legacy-ml&#x2F;gcc&#x2F;2017-08&#x2F;msg00121.html" rel="nofollow">https:&#x2F;&#x2F;gcc.gnu.org&#x2F;legacy-ml&#x2F;gcc&#x2F;2017-08&#x2F;msg00121.html</a>
theamk超过 1 年前
The cancellation is the main reason why I usually end up with async frameworks in C++ (like boost::asio). When you have explicit event loop, the whole cancellation thing is so much easier to reason about.<p>And even if your don&#x27;t want to do full-featured event loop and like synchronous style, it&#x27;s pretty simple to add &quot;poll&quot; call to each network read (on just 2 descriptors: &quot;termination pipe&quot; and the FD you are interested in). Sure, it requires a custom wrapper for read&#x2F;write&#x2F;connect, but so is author&#x27;s proposed signal-safe syscall.
squarefoot超过 1 年前
I burned myself with threads back in the day under AIX when I had this process creating and destroying them, and after destroying them they were still visible and their resources still there. A few posts on Usenet (good times!) and knowledgeable people instructed me on what a thread pool was and why I should have used one instead of creating and destroying threads. I can&#x27;t give more details, that was like 25 years ago and my memory modules have no parity check, but the experience was very instructional.
pornel超过 1 年前
The article does a great job of shattering all hopes.
otabdeveloper4超过 1 年前
Thread cancellation works fine in C++.<p>You just need to make sure cancellable syscalls do not happen in destructors. (Which you probably want to do anyways, since cancellable syscalls can cause errors that are difficult to handle in destructors.)<p>Good practice is to move destructed objects to a &quot;garbage collection&quot; thread which calls the real destructors and cannot be cancelled.
评论 #38913081 未加载
评论 #38914828 未加载