是否可以在不使用 SIGHUP 的情况下立即启动 pthread？答案

【问题标题】：Is it possible to start a pthread immediately without using SIGHUP?是否可以在不使用 SIGHUP 的情况下立即启动 pthread？
【发布时间】：2016-04-27 22:37:57
【问题描述】：

是否可以立即启动由pthread_create 创建的线程而无需等待~300us 才能启动？现在，现有代码正在通过向线程发送SIGHUP 来“启动”线程，但是，副作用是如果主进程没有为SIGHUP 设置信号处理程序，则该进程将放弃吧……

我可以让它处理SIGHUP，但是我想知道是否有比这种方式更好的解决方案...

注意：问题的初始版本说“300 毫秒”，导致 cmets 认为 300 毫秒太长了。 300 微秒更合理。

【问题讨论】：

三百毫秒？你确定吗？你能发布一个工作示例吗？
你的意思是微秒吗？
我多次使用pthread_create，但从未使用SIGHUP信号，所以我猜答案是肯定的。
@codenamezero 您是否在单核系统上运行？我会尝试在 pthread_create() 之后立即调用 sched_yield() 以查看是否可以更快地切换到新线程。无论如何，新线程开始运行的 300 毫秒在任何情况下都是不正常的，因此您的代码或平台必须有更多正常的东西。
同意没有。即使在多核系统上，创建线程也不应该使用 CPU 来等待新线程。这适得其反。让步是一种快速破解，SIGHUP 是一种奇怪且有问题的让步方式，进行阻塞等待是正确的解决方案。

标签： c++ linux multithreading pthreads signals

【解决方案1】：

在修复了几个小时之后，另一种方式来归档我需要的内容。顺便说一句，我尝试按照@nos 的建议使用sched_yield，但这并没有产生任何不同的行为。

作为更新，我想指出我正在使用的代码正在执行do...while 循环，以通过发送SIGHUP 来探测pthread 是否完成。

我的问题的解决方案是发送自定义sigaction，如下所示：

有一个虚拟信号处理程序：

void thread_signal_handler(int sig) { }

然后在我正在使用的图书馆中，在发送SIGHUP之前：

...
struct sigaction sa;
sa.sa_handler = dummy_handler;
sa.sa_flags = 0;
sigemptyset(&sa.sa_mask);
sigaction(SIGHUP, &sa, NULL);
pthread_kill(tid, SIGHUP);
...

这样做，我的应用程序不需要处理SIGHUP 信号。

【讨论】：

你为什么使用SIGHUP，而不是默认非致命的信号？如果SIGCONT、SIGCHLD 或SIGURG 仍然可以解决您的问题，您不必将它们设置为忽略。 SIGCONT 的默认操作是从停止状态恢复，而根据signal(7)，默认情况下 SIGCHLD 和 SIGURG 都被忽略。忽略SIGHUP 意味着您的程序将在某些情况下继续运行，如果人们在退出时希望它在后台退出的话。