升压信号灯linux下和EINTR返回代码

在升压（我用1.54.0）我看到POSIX信号等待执行：升压信号灯linux下和EINTR返回代码

inline void semaphore_wait(sem_t *handle) 
{ 
    int ret = sem_wait(handle); 
    if(ret != 0){ 
     throw interprocess_exception(system_error_code()); 
    } 
}

手册上的POSIX信号说：

错误

EINTR The call was interrupted by a signal handler; see signal(7).

我是正确的，如果我发送杀死等待的线程提高信号量抛出异常？如果是的话，你如何处理这种情况？

来源

2015-04-06 Dmitry Poroh

不要发送kill到线程，除非线程被设计为处理它。 – 2015-04-06 09:31:53

@DavidSchwartz在一般情况下，我无法确定它是否为它设计。另外，我可以获得类似SIGPIPE的东西，这在TCP应用程序中很常见，因为当你发送连接到RST的东西时。 – 2015-04-06 09:35:32

如果你不知道线程会对信号做什么，为什么你会发送信号给线程？向线程发送信号的唯一原因是因为您知道该线程在获取该信号时设计要执行的操作，并且您希望这样做。主题*必须*合作。 – 2015-04-06 09:52:33

在我看来，这可能是Boost.Interprocess中的一个错误。请向开发人员报告，至少他们能够提供一个理由，如果这是故意的。

评论上述评论中的信号管理建议。确实，一个典型的多线程应用程序应该掩盖那些不打算由线程处理的信号，只留下一个线程来处理信号。但是，这不是强制性规则。

首先，辅助线程可以由内部不处理信号的库产生，并将其留给应用程序。信号处理程序可以在这些线程中被调用。其次，某些信号可能会被有意留下，以便捕获与该特定线程相关的事件。例如，可以注册SIGSEGV的处理程序来检测分割错误。该处理程序将在违规线程中调用，并且应用程序理论上可以处理该错误。同样，SIGUSR1或SIGUSR2可用于向应用程序定义的事件发送特定线程信号。

底线是，即使一个设计良好的应用程序应该将信号处理提取到一个单独的线程，库不应该假设它并且没有做好准备。无论如何，在EINTR的情况下抛出看起来不是一个正确的行为。

来源

2015-04-06 15:49:00

我已经在此创建了票https://svn.boost.org/trac/boost/ticket/11172。让我们看看他们会回答什么。谢谢。 – 2015-04-07 12:19:05

实现看起来不错。可以使用SA_RESTART标志，以便呼叫自动重新启动。 http://man7.org/linux/man-pages/man7/signal.7.html

来源

2015-12-22 11:06:08 Savis

升压信号灯linux下和EINTR返回代码

回答

相关问题