微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

关于预期行为的一般信号问题

如何解决关于预期行为的一般信号问题

场景一

假设存在以下场景。

我的程序调用一个 3rd 方库,后者又调用了另一个 3rd 方库,后者反过来进行了操作系统调用

   MyProgram
        |
   some3rdPartyFunction() ---> 3rd party library
                                 |
                             another3rdPartyFunction()----> another 3rd party library
                                                                      |
                                                                    OS call()

第一组问题:

  • 如果此操作系统调用关闭套接字进行套接调用,会发生什么?
  • 是否向进行操作系统调用的进程返回了错误
  • 系统在什么时候返回 SIGPIPE 消息?
  • SIGPIPE 是只发送给调用函数还是 SIGPIPE 一直传播到 MyProgram?

场景 2

我碰巧看到了进程的线程转储的以下输出

rt_sigprocmask(SIG_SETMASK,...)
rt_sigreturn({mask=[PIPE]})
rt_sigprocmask(SIG_SETMASK,[],NULL,8) = 0
rt_sigaction(SIGINT,8) = 0
rt_sigaction(SIGTERM,8) = 0
rt_sigaction(SIGHUP,8) = 0
rt_sigaction(SIGABRT,8) = 0
rt_sigprocmask(SIG_SETMASK,8) = 0
rt_sigreturn({mask=[PIPE]})

第二组问题:

  • 为什么要发送这么多信号信息?
  • 这些会直接发送到 MyProgram 还是被传播 从较低的操作系统调用开始?
  • 随着发送的信号种类繁多,如何确定哪一个是 实际上是造成问题的原因吗?

解决方法

如果此操作系统调用对关闭的套接字进行套接字调用,会发生什么?

好吧,在谈论文件描述符(可能已关闭)和流套接字(如 TCP,可能部分或完全关闭)时,“关闭”可能有点误导。我认为您要问的是 write() call error POSIX 文档为:

[EPIPE] 尝试在已关闭以进行写入或不再连接的套接字上进行写入。在后一种情况下,如果套接字是 SOCK_STREAM 类型,则还应向线程发送 SIGPIPE 信号。

是否向进行操作系统调用的进程返回了错误?

错误返回到任何名为 write 的代码位,并为最终调用 write线程 生成信号。

系统在什么时候返回 SIGPIPE 消息?

尝试写入不可写的套接字或管道时生成 SIGPIPE。

SIGPIPE 是只发送到调用函数还是一直传播到 MyProgram?

SIGPIPE 是为调用线程生成的。它在调用链中的位置(您的程序、第 3 方库等)与信号传递无关。

为什么要发送这么多信号信息?

您显示的内容中没有发送任何内容。大多数调用都是关于屏蔽和信号处理,不是信号生成。 rt_sigreturn 调用告诉您 Linux is handling the delivery of a SIGPIPE

这些是直接发送到 MyProgram 还是从较低的操作系统调用向上传播?

我不明白这是什么意思。 SIGPIPE 是为您进程中的特定线程生成的,无论您在 MyProgram 中的代码是否知道该线程的存在,或者 3rd 方库是否“秘密地”创建了该线程。

随着发送的信号种类繁多,如何确定究竟是哪个信号引起了问题?

在您展示的内容中只生成了一个信号,那就是 SIGPIPE。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。