g_io_channel和FIFO导致CPU挂起到100％

Question

当我将FIFO与g_io_channel结合使用时，我试图理解为什么我的CPU固定为100％。

我在github上有一个项目，用尽可能小的设置来演示问题;只是一个在/ tmp中打开FIFO的简单服务器，以及一个通过该FIFO向服务器发送消息的客户端。

我找到了：

1. 首次启动时，服务器接近零CPU
2. 客户端一旦通过FIFO向服务器发送消息，服务器就会接收并打印消息，然后CPU将达到100％。
3. 您可以继续通过FIFO发送消息，服务器将打印它们，但CPU保持100％： - /

我已经尝试过通常的谷歌和堆栈溢出，但到目前为止找不到解决方案的乐趣。我希望有人能帮助我了解正在发生的事情。我相信我正在使用glib / GTK，但我很高兴能够得到纠正。我感谢您提供的任何帮助。谢谢！

Answer 1

通过使用strace运行服务器，我发现在返回poll()事件时，它只是在循环中调用POLLHUP。问题似乎是您希望能够无限期地等待G_IO_IN个事件，告诉您数据即将到来，但不要管理G_IO_HUP告诉您连接已关闭。

然后我在bluez code中找到了这条评论：

if (cond & (G_IO_ERR | G_IO_HUP)) {
        /*
         * Both ends needs to be open simultaneously before proceeding
         * any input or output operation. When the remote closes the
         * channel, hup signal is received on this end.
         */
        fifo_open();
        return FALSE;
}

这个问题解释了所有：Poll() on Named Pipe returns with POLLHUP constantly and immediately

这就是我在strace看到的内容：当客户端进程退出时（您或者只是一个简单的echo到您的fifo），IO通道被通知另一方连接被绞死了。您的客户端当前发送消息并关闭连接。所以你要么让它保持连接活着而不是断开连接，要么你需要重新打开fifo服务器端并添加一个新的手表，或者在我链接的SO问题中使用mark4o，you open the fifo with read/write rights server-side这样你就可以了在fifo（服务器）上至少有一个编写器，避免挂起。

例如，我链接的bluez代码关闭通道并在断开连接时打开一个新通道。小心也要注意代码中的引用计数问题。