BOOST :: thread删除可连接线程有什么问题? [英] BOOST::thread what problems are there in deleting a joinable thread?

问题描述

破坏一个可连接的线程指针可能会遇到什么问题? (即调用delete thread)增强参考有点模糊，需要更准确的答案.

What are the problems one could encounter from destroying a joinable thread pointer? (i.e. calling delete thread) The boost reference is a bit fuzzy, more exact answers are desirable.

这是一个具体示例:

假定子线程卡在诸如read(0)之类的不可中断系统调用上，而没有人值守键盘.因此，调用thread->interrupt()后跟thread->try_join_for()将使线程保持可连接状态.应该怎么办?

Assume a child thread is stuck on a non-interruptable system call such as read(0) with no one manning the keyboard. Thus, calling thread->interrupt() followed by a thread->try_join_for() will leave the thread joinable. What should be done?

从参考指南看来，似乎必须分离线程或泄漏线程指针.当卡住的线程被分离或指针泄漏时实际发生的情况超出了此问题的范围.

From the the reference guide, it seems that one must either detach the thread or leak the thread pointer. What actually happens when a stuck thread is detached or pointer leaked are outside of the scope of this question.

背景:

在boost::thread::~thread()参考中是以下文字.作为BOOST参考指南中的她在海边卖贝壳"，它需要阅读三到四次才能解析；

In the boost::thread::~thread() reference is the following verbiage. Being the "she sells seashells by the seashore" of the BOOST reference guide, it requires reading three or four times before one can parse it;

在析构函数中隐式分离或联接joinable()线程可能导致难以调试仅在引发异常时遇到的正确性(对于分离)或性能(对于联接)错误. 因此，程序员必须确保在线程仍可连接时永远不要执行析构函数.

(据我所知)的不足之处是(一个)(坏)主意(要)销毁(一个)boost::(线程)指针(而)(仍然)还(可加入).谁在提出提到的例外?子线程?破坏者?

The short of this (from what I can tell) is (that) it (is) a (bad) idea (to) destroy (a) boost::(thread) pointer (while) it (is) still (joinable). And who's raising the exception mentioned? The child thread? The destructor?

推荐答案

这要视情况而定.最初，Boost的实现会在销毁时分离未连接的线程.自版本1.52以来，已更改，以匹配C ++ 11的std::thread:销毁未连接的线程现在会调用 std::terminate (这将导致崩溃程序).直到1.56和.

It depends. Originally Boost's implementation would detach an unjoined thread upon destruction. This has been changed since version 1.52 to match the behavior of C++11's std::thread: Destroying an unjoined thread now invokes std::terminate (which will crash the program by default). The old behavior will remain available as a deprecated feature until 1.56 and can be activated by setting the BOOST_THREAD_DONT_PROVIDE_THREAD_DESTRUCTOR_CALLS_TERMINATE_IF_JOINABLE preprocessor flag.

因此，对于阻塞在阻塞调用中的线程的示例，建议必须为:不要这样做.仅使用允许指定超时的阻塞I/O调用，或者改用异步I/O.您需要能够发出信号通知正在等待I/O的线程应该终止，否则您将有可能在关闭程序时陷入死锁.

For your example of a thread that is stuck in an a blocking call the advice must therefore be: Don't do it. Only use blocking I/O calls that allow specifying a timeout or use asynchronous I/O instead. You need to be able to signal a thread waiting for I/O that it should terminate, otherwise you risk a deadlock when shutting down your program.

从理论上讲，您不能加入线程(即分离或泄漏boost::thread对象).但是，这通常会引起很多其他麻烦，因为您不能保证该线程所拥有的资源将被适当地清理.这使得很难对这种线程的行为进行推理.请记住，ISO-C ++确实决定在此处调用terminate是出于某种原因.

Theoretically you could just not join the thread (ie. either detach or leak the boost::thread object). However this usually causes lots of other headaches, as you cannot guarantee that resources held by that thread will be cleaned up appropriately. This makes it very hard to reason about the behavior of such a thread. Mind that ISO-C++ did decide to invoke terminate here for a reason.

这篇关于BOOST :: thread删除可连接线程有什么问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！