在boost(我使用1.54.0)中,我看到了posix信号量等待的实现:
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).
如果我向等待线程发送kill,那么我是否正确提升信号量抛出异常?如果是这样,你如何处理这种情况?
答案 0 :(得分:0)
在我看来,这可能是Boost.Interprocess中的一个错误。请向开发人员报告,至少他们将能够提供理由,如果这是故意的。
在上述评论中评论信号管理建议。确实,典型的多线程应用程序应该屏蔽掉不打算由线程处理的信号,只留下一个线程来处理信号。但是,这不是强制性规则。
首先,辅助线程可以由库生成,这些库不在内部处理信号,而是将其留给应用程序。可以在这些线程中调用信号处理程序。
其次,有些信号可能会被故意保留,以捕获与该特定线程相关的事件。例如,可以为SIGSEGV注册处理程序以检测分段错误。这个处理程序将在违规线程中调用,理论上应用程序可以处理错误。类似地,SIGUSR1或SIGUSR2可用于向特定线程发送应用程序定义的事件。
最重要的是,即使一个设计良好的应用程序应该将信号处理提取到一个单独的线程,库也不应该假设它并且做好准备它不会。在任何情况下,抛出EINTR的情况看起来都不正确。
答案 1 :(得分:0)
实施看起来不错。可以使用SA_RESTART标志,以便自动重新启动呼叫。 http://man7.org/linux/man-pages/man7/signal.7.html