在运行线程程序并使用Ctrl + C重复终止主程序时，我在第二次运行中看到程序中的意外结果。但是，如果我让程序运行并自愿退出，则没有问题。
所以，我怀疑，Ctrl + C是否也会杀死线程以及主进程？
提前致谢。
答案 0 :(得分：3)
在多线程编程中，信号被传递到单个线程（通常在没有阻塞特定信号的线程中不可预测地选择）。但是，此并不意味着默认操作将终止进程的信号仅终止一个线程。事实上，没有办法杀死单个线程而不会杀死整个进程。
只要您使SIGINT使用其终止进程的默认操作，只要至少有一个线程离开SIGINT未阻止，它就会执行此操作。只要至少有一个线程将哪个线程解除阻塞并不重要，因此在应用程序后面创建线程的库代码应始终在调用pthread_create之前阻塞所有信号，然后在调用线程中恢复信号掩码。
答案 1 :(得分：2)
嗯，Ctrl + C唯一能做的就是在进程中将SIGINT发送到一个线程，而不会屏蔽信号。信号可以被处理或忽略。
如果程序 处理Ctrl+C，通常的行为是自我终止，但再一次，它可以用于其他任何事情。
在你的情况下，一个线程正在接收SIGINT，这可能会自行杀死，但不会杀死其他线程。
答案 2 :(得分：1)
在Linux 2.6下使用NPTL线程：我假设进程使用默认信号处理程序，或者在其中调用exit（）：是的。 C库exit（）调用映射到exit_group系统调用，该调用立即退出所有线程;默认信号处理程序调用此类或类似的东西。
在Linux 2.4下使用Linuxthreads（如果您的应用程序仍然使用Linuxthreads出于某种奇怪的原因，则使用2.6）：不一定。
Linuxthreads库使用clone（）实现线程，创建一个新的进程，恰好与父进程共享其地址空间。当父母去世时，这不一定会死亡。要解决这个问题，pthreads会创建一个“主线程”。这个主线程执行各种操作，其中之一是尝试确保在进程退出时（无论出于何种原因）所有线程都被杀死。
所以，如果您使用的是Linuxthreads，可能不是。
其他线程可能不会立即退出，或者根本不退出。
但是，无论您使用什么线程库，分叉子进程都将继续（如果它们仍在同一进程组中，它们可能会收到信号，但可以自由忽略它）