需要保证信号将由违规线程传递
我正在开发一个项目，但找不到任何验证以下情况的信号/线程行为的文档。
我需要确保线程中生成的信号将由有问题的线程（即 SIGSEGV）传递。我被告知，POSIX 不能确保这种行为，例如，pthreads 可以在 pthread 1 中生成信号，但具有信号在pthread 2中传递。因此，我计划使用 clone(2) 来更好地控制信号/线程行为，但仍然无法在手册页中找到确保信号将由有问题的线程传递的文档。
核心系统程序员：任何文档或见解将不胜感激！
I'm working on a project and cannot find any documentation that verifies signal/thread behavior for the following case.
I need to ensure that signals generated in a thread will be delivered by the offending thread (namely, SIGSEGV). I've been told that POSIX doesn't ensure this behavior and that pthreads, for example, can generate signals in pthread 1 yet have the signal delivered in pthread 2. Therefore, I'm planning on using clone(2) to have finer control of signal/thread behavior, but still cannot find documentation in the man pages that ensures signals will be delivered by the offending thread.
Hardcore systems programmers: any documentation or insights would be very much appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
关于信号生成和传递的 POSIX 章节指出：
由线程中不正确的内存访问引起的同步
SIGSEGV显然是这样一个信号“...由可归因于特定线程的某些操作生成...”，因此它们保证是为有问题的线程生成的（这意味着由该线程酌情处理或忽略）。The POSIX chapter on Signal Generation and Delivery states that:
A synchronous
SIGSEGVcaused by an incorrect memory access in a thread is clearly such a signal "...generated by some action attributable to a particular thread...", so they are guaranteed to be generated for the offending thread (which means handled or ignored by that thread, as appropriate).我很确定这会起作用，即使不能保证。我的这一观察基于这样一个事实：我曾经在一家公司工作，我们经常在多线程程序中处理 SIGSEGV 并将堆栈跟踪打印到日志文件（基于当前位置）。我们在各种平台上做到了这一点——windows、linux、tru64 unix、aix、hpux、sunos……也许还有一两个我不记得的其他平台。这（通常！）是有效的，因为 SIGSEGV 的位置仍在当前堆栈上（信号处理机制只是在其顶部添加了一些调用帧）。
公平地说，您在信号处理程序中几乎不需要做任何事情，因为没有多少函数是异步信号安全的。我们忽略了这一点，并且大部分都侥幸逃脱了，除非我记得在 sunos（或 aix）上我们会被烧毁——该过程偶尔（并且看似随机）在信号处理程序内硬退出。
我相信推荐的方法是不处理 SIGSEGV，并让进程通过核心转储退出，以便您稍后可以在调试器中进行分析。
I'm pretty sure this works, even if it isn't guaranteed. I base this observation on the fact that I used to work at a company where we routinely handled SIGSEGV in multithreaded programs and printed a stack trace to a log file (based on currently location). We did this on a variety of platforms--windows, linux, tru64 unix, aix, hpux, sunos ... and maybe one or two others that I can't recall. This (usually!) works because the location of SIGSEGV is still on the current stack (the signal handling mechanism just adds a few call frames over top of it).
It's only fair to mention that there's very little that you should do in a signal handler because there aren't many functions that are async signal safe. We ignored this and mostly got away with it, except if I recall on sunos (or aix) where we would get burned--the process would occasionally (and seemingly randomly) hard exit inside the signal handler.
I believe the recommended approach is to NOT handle SIGSEGV, and let the process exit with a core dump so you can analyze later in a debugger.