处理 SIGPIPE
在网络编程中经常会遇到SIGPIPE
信号,默认情况下这个信号会终止整个进程,当然你并不想让进程被SIGPIPE
信号杀死。我们不禁会这样思考:
- 在什么场景下会产生
SIGPIPE
信号? - 要怎样处理
SIGPIPE
信号?
SIGPIPE
产生的原因是这样的:如果一个 socket 在接收到了 RST packet 之后,程序仍然向这个 socket 写入数据,那么就会产生SIGPIPE
信号。
这种现象是很常见的,譬如说,当 client 连接到 server 之后,这时候 server 准备向 client 发送多条消息,但在发送消息之前,client 进程意外奔溃了,那么接下来 server 在发送多条消息的过程中,就会出现SIGPIPE
信号。下面我们看看 server 的代码:
我们可以使用 Linux 的 nc 工具作为 client,当 client 连接到 server 之后,就立即杀死 client (模拟 client 的意外奔溃)。这时可以观察 server 的运行情况:
让我们分析一下整个过程:
- client 连接到 server 之后,client 进程意外奔溃,这时它会发送一个 FIN 给 server。
- 此时 server 并不知道 client 已经奔溃了,所以它会发送第一条消息给 client。但 client 已经退出了,所以 client 的 TCP 协议栈会发送一个 RST 给 server。
- server 在接收到 RST 之后,继续写入第二条消息。往一个已经收到 RST 的 socket 继续写入数据,将导致
SIGPIPE
信号,从而杀死 server。
对 server 来说,为了不被SIGPIPE
信号杀死,那就需要忽略SIGPIPE
信号:
重新运行上面的程序,server 在发送第二条消息的时候,write()
会返回-1
,并且此时errno
的值为EPIPE
,所以这时并不会产生SIGPIPE
信号: