c - 在 Linux 上处理多线程断管情况的服务器端套接字最佳实践是什么？

Question

考虑到我是 Linux 上的 C 语言新手，我已经了解了必须处理 SIGPIPE 问题的套接字编程场景，并且我遇到了以下情况:
1-捕获进程的sigaction然后继续，这相当于忽略该信号。

struct sigaction sginal_action;
memset(&sginal_action, 0, sizeof (sginal_action));
sginal_action.sa_handler = SIG_IGN;
sginal_action.sa_flags = SA_RESTART;
if (sigaction(SIGPIPE, &sginal_action, null)) {
    perror("signal action error"); 
}

2- 使用

忽略线程上的信号

sigset_t sigpipe_mask;
sigemptyset(&sigpipe_mask);
sigaddset(&sigpipe_mask, SIGPIPE);
sigset_t saved_mask;
if (pthread_sigmask(SA_RESTART, &sigpipe_mask, &saved_mask) == -1) {
  perror("pthread_sigmask");
}

- 现在一切都会正常工作，但我需要有关此测试用例行为的答案:

1- 服务器接受来自用户 A 的套接字，文件描述符为 int 7
2-我运行了冗长的 SQL 语句，需要 25 秒
3-在第二个 20 客户端关闭套接字
4- 在第二个 21 Linux 内核发送 SIGPIPE
5-在第 22 秒，进程忽略了 SIGPIPE 并继续使用文件描述符 7，因为没有任何信号表明出现任何问题
6-在第 23 秒，服务器再次接受来自用户 B 的套接字，文件描述符为 int 7!
7- 用户 B 授权需要 2 秒，应在用户 A 的第 25 秒完成。
8- 核心问题开始在第 25 秒 write(file_dsciptor, buffer, buffer_size);两个线程都会将数据写入用户 A 和用户 B channel
9- 碰巧用户 B 无权登录服务器，但在服务器在线程 B 处关闭文件描述符 7 之前，客户端 A 的线程 A 写入文件描述符 7，并且由于重用套接字文件描述符 7，客户端 B 收到了重要数据!

我的问题是，
这种情况是错误的并且永远不会发生吗？
还是有可能发生，但有正确的方法可以应用？
是否有一个 C 系统调用函数来停止 file_discriptor通过套接字连接重新使用？
或者应该采取什么措施来确保打开的 channel 不与另一个 channel 冲突，比如我猜的唯一文件描述符？

Answer 1

(正常)SIGPIPE本质上是一个同步信号。你得到它是为了响应你所做的事情，即尝试写入被另一端关闭的管道/套接字/FIFO。忽略 SIGPIPE 是非常无害的，因为如果您这样做，您仍然会以报告同步错误的通常方式收到有关错误的通知:通过失败的返回代码和 errno 设置相应的错误号 (EPIPE)。在这种情况下，我认为忽略 SIGPIPE 同时继续检查错误将是继续操作的最佳方法，无论您使用什么 POSIX 平台。

关于您的示例，您在第 5 点的假设“没有信号表明出现任何问题”是不正确的。会有信号。它只是不会成为信号，而是 EPIPE 在 write 调用上失败。