sigprocmask 不工作
我使用 sigprocmask 如下：
void mask(){
sigset_t new_set,old_set;
sigemptyset(&new_set);
sigaddset(&new_set,SIGALRM);
sigprocmask(SIG_BLOCK, &new_set, &old_set);
}
令我惊讶的是，打印一个大列表的函数不知何故被信号中断，即使我在其开头调用 mask() 。 看起来 mask 好像失败了，因为我的函数没有调用任何其他函数，因此在运行过程中不会发生 unmask() 。 什么会导致 sigprocmask 失败？
I'm using sigprocmask as follows:
void mask(){
sigset_t new_set,old_set;
sigemptyset(&new_set);
sigaddset(&new_set,SIGALRM);
sigprocmask(SIG_BLOCK, &new_set, &old_set);
}
and to my surprise a function which prints a big list somehow gets interrupted by the signal, even though I invoke mask() at its beginning.
It looks as if mask fails, since my function doesn't invoke any other functions and therefore nowhere in its run should an unmask() happen.
What can cause sigprocmask to fail?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据 POSIX 规范，
sigprocmask()返回 -1 并相应地设置 errno如果失败了。如果您发布的代码是您正在使用的代码，那么您显然不会检查它是否成功。如果
sigprocmask()成功，并且确实是SIGALRM正在中断调用mask()的函数，则存在 很有可能该函数中的某些内容正在以不同的方式处理该信号。您可以做的另一件事是在调用 mask() 后立即 raise(SIGALRM) ，如果它被忽略，则下面的其他一些函数正在改变行为。
正如评论中指出的 bmargulies （这可能应该是一个答案），您可以使用
strace看看情况是否确实如此，如果适用的话，再加上 ltrace 来观察它逐步执行库调用。当您使用在安装处理程序时粗鲁的库时，这种情况并不罕见（例如，在修改行为之前检查信号是否被忽略或在其他地方处理）。
From the POSIX spec,
sigprocmask()returns -1 and sets errno accoringly if it fails. If the code that you posted is the code you are using, you obviously aren't checking to see if it succeeded.If
sigprocmask()is successful, and it is indeedSIGALRMthat is interrupting the function that is callingmask(), there is a very good chance that something within that function is handling that signal differently.The other thing you can do is
raise(SIGALRM)immediately after callingmask(), if its ignored, then some other function below that is changing the behavior.As bmargulies noted in comments (that probably should have been an answer), you can use
straceto see if that is indeed the case, coupled withltraceif applicable to watch it step through library calls.This is not at all uncommon when you work with libraries that are rude when it comes to installing handlers (e.g. checking to see if a signal is ignored, or handled elsewhere prior to modifying the behavior).