R..*_*R.. 9 c linux posix pthreads cancellation
我正在努力在Linux上实现pthread取消,而不会在我最近的一些其他问题中讨论任何"不愉快的行为"(有些人可能会说错误).到目前为止,取消pthread取消的Linux/glibc方法一直将它视为不需要内核支持的东西,并且可以在库级别处理,纯粹通过在进行系统调用之前启用异步取消,并恢复先前的取消状态在系统调用返回后.这至少有两个问题,其中一个非常严重:
我解决问题的第一个想法是设置一个标志,线程处于取消点,而不是启用异步取消,并且当设置此标志时,让取消信号处理程序检查保存的指令指针,看它是否指向系统调用指令(特定于arch).如果是这样,这表示系统调用未完成,并且在信号处理程序返回时将重新启动,因此我们可以取消.如果没有,我认为系统调用已经返回,并推迟取消.但是,还存在竞争条件 - 线程可能根本没有到达syscall指令,在这种情况下,系统调用可能会阻塞并且永远不会响应取消.另一个小问题是,如果在输入信号处理程序时设置了取消点标志,则从信号处理程序执行的不可取消的系统调用会被错误地取消.
我正在寻找一种新的方法,并寻找有关它的反馈.必须满足的条件:
我想到的想法需要为可取消的系统调用包装器进行专门的组装.基本想法是:
取消操作将涉及:
取消信号处理程序然后:
到目前为止我看到的唯一问题是信号处理程序的第1步:如果它决定不动作,那么在信号处理程序返回之后,线程可能会在系统调用上被阻塞,忽略待处理的取消请求.为此,我看到了两个可能的解决方案:
关于哪种方法最好的想法,或者是否还有其他更基本的缺陷?
解决方案 2 感觉不太像 hack。我认为这不会导致您建议的问题,因为在系统调用处理程序中调用的可取消系统调用将检查 TLS 中的取消标志,如果取消信号处理程序已运行并无论如何都使用信号掩码,则该标志必须已经设置。
sigmask
(如果每个阻塞系统调用都采用一个参数 la ,那么对于实现者来说似乎会容易得多pselect()
)。