我正在研究在Linux / OS X下用C编写的线程命令行应用程序，它执行一些数值计算。到目前为止，这些计算总是设置为运行到给定的迭代次数。现在，我们已经开始在命令行中进行交互：运行直到
在某个任意时间点停止系统中的所有组件（计算线程，以及组装最终结果的主线程并通过pthread_cond_wait()等待，直到有东西要组装）都没有问题：已经存在功能，可以通过向应用程序发送SIGUSR1信号来实现此目的。
问题是在主线程应用程序中添加，直接用户I / O通过它启动的终端的可能性。而且甚至连交互本身也让我感到头痛：在计算阶段添加另一个主动寻求用户输入的线程很容易。对用户输入采取行动是微不足道的（提前终止应用程序的机制就在那里）。
问题是案例B，可以这么说：如果用户根本没有按任何键，并且达到迭代限制怎么办？一旦达到迭代限制，应用程序中的所有线程都知道如何以有序的方式关闭自己：好吧，除了一个之外的所有线程。让用户输入线程正常关闭超出了我的范围：目前，I / O线程在read()上使用标准阻塞I / O stdin。在整个应用程序终止之前，它仍然是各种各样的僵尸。这本身并不会造成伤害，但留下像这样的悬挂线是绝对不洁净的。
我尝试通过stdin从其他线程中提供适当的输入，这些线程知道应用程序在达到迭代限制后正在关闭。但是无法让这个工作 - 并且将提供给 stdin似乎是一个狡猾的想法。这里的想法是用户输入线程上的阻塞read()被提供一个假的用户输入以使其关闭 - 但它永远不会收到我提供给stdin的任何内容。
用户I / O线程上的read()是标准的：
char line[256]; int len;
len = read( STDIN_FILENO, line, 256 );
并且在另一个帖子中将内容发送到stdin的失败尝试之一是：
write( STDIN_FILENO, "q\n", 2 );
我在这里做错了什么？ （字母q在终端中显示为输出，FWIW）在用户交互线程中使用阻塞I / O首先是一个愚蠢的想法吗？或者我是否应该尝试优雅地关闭I / O线程，并以某种方式杀死它？或者是否有一种特殊的read()也可以通过其他方式唤醒？或者我只是把“喂食给stdin部分”搞砸了？