C pthread_kill（）使用是否危险？

我已经读到WinAPI中的

TerminateThread（）

使用起来很危险

在Linux中使用

pthread\u kill（）

是否也很危险

---

---

编辑：对不起，我的意思是

pthread\u kill（）

而不是

pthread\u exit（）

引用汉弗莱·阿普比爵士的话，答案是“是，也不是”

调用pthread_exit（）本身并不危险，并且在线程退出其方法时隐式调用。但是，如果您手动调用它，则会出现一些“陷阱”

调用此函数时，将调用所有清理处理程序。因此，如果调用此方法，然后访问清理处理程序已清理的内存，则会出现内存错误

类似地，调用此函数后，线程的任何局部变量和线程局部变量都将无效。因此，如果对它们进行引用，则可能会出现内存错误

如果已经为线程（隐式或显式）调用了该函数，则再次调用该函数具有未定义的行为，并且

如果这是进程中的最后一个线程，这将导致进程退出

如果您注意上述事项（即，在调用pthread_exit后，如果您注意不引用有关线程的任何内容），那么手动调用call是安全的。但是，如果您使用C++而不是C，我将强烈建议使用STD::Type类，而不是手动进行。它更容易阅读，涉及的代码更少，并确保您不会破坏上述任何一项

---

有关更多信息，请键入“man pthread_exit”，它将基本上告诉您上述内容。

由于问题现在已更改，我将编写一个新的答案。我的答案仍然是“是”和“不是”，但原因已经改变了

pthread_kill有些危险，因为它分担了所有信号处理系统固有的潜在计时风险。此外，处理它还存在复杂性，特别是必须在线程中设置信号处理程序。然而，有人可能会说它没有你提到的Windows功能那么危险。原因如下：

Windows函数基本上停止线程，可能会绕过正确的清理。这是作为最后的选择。另一方面，pthread_kill根本不会终止线程。它只是向线程发送一个线程可以响应的信号

为了让它做一些事情，你需要在线程中注册你想要它处理的信号。如果您的目标是使用pthread_kill终止线程，那么您可以通过让信号处理程序设置线程可以访问的标志，并让线程检查该标志并在设置后退出来使用它。您可以从信号处理程序调用pthread_exit（我从未尝试过），但我觉得这是个坏主意，因为信号是异步发出的，并且您的线程不能保证仍在运行。我提到的标志选项解决了这一问题，前提是该标志不是线程的本地标志，允许信号处理程序设置它，即使目标线程已经退出。当然，如果您正在这样做，您根本不需要pthread_kill，因为您可以让主线程在适当的时间设置标志

还有另一个停止另一个线程的选项-pthread_cancel方法。此方法将在目标线程上放置取消请求，如果该线程已配置为可取消（通常在pthread_create中执行此操作，但也可以在事实发生后执行），则下次线程到达潜在取消点时（由pthreadu testcancel指定，但也由许多系统例程（如IO调用）自动处理），它将退出。这也比Windows所做的更安全，因为它不会猛烈地停止线程-它只在定义良好的点停止。但它比Windows版本更为复杂，因为您必须正确配置线程

---

“posix线程”的Wikipedia页面描述了其中的一些（但不多），但它有一个非常好的“请参阅”和“参考资料”这一部分将为您提供更多详细信息。

并做不同的事情。也许您会思考？为什么您会这样想？它们完全不同。至于为什么

TerminateThread

和

pthread\u kill

可能是“危险的”，想想如果线程分配了大量的资源，然后它们被简单地杀死而没有机会自己清理？或者，如果它们正在编写一个文件，那么该文件会发生什么情况？也许您应该尝试了解为什么

TerminateThread（）

是危险的…看起来你把pthread\u kill和pthread\u exit弄混了。\u exit终止调用，而\u kill向另一个thread发送信号不，我只是仔细检查了一下，“man pthread\u exit”确认了我上面说的一切。也许提问者的意思是“pthread\u kill”但我选择回答被问到的问题，而不是猜测他们是否想问这个问题。如果将原始问题修改为询问pthread_kill是否危险，那么明确的答案是“是”。向线程发送信号会带来所有潜在的安全风险（特别是潜在的时间问题）这存在于向进程发送信号的过程中。另外请注意，pthread_kill不会停止线程-它只是向它发送一个信号。啊，我的错误。对不起。这在技术上是正确的-pthread_exit与到达其返回的线程函数没有什么不同，但是触发“gotchas”更难在后一种情况下，我还应该注意，处理pthread_cancel也不是一件小事，但这是另一种讨论。