Предположим, что приложение заблокировано в точке отмены, например read
, и принимается сигнал и вызывается обработчик сигнала. Glibc/NPTL реализует точки отмены, позволяя асинхронное аннулирование на время syscall, насколько я могу судить, асинхронное аннулирование останется в силе на всю длительность обработчика сигнала. Это, конечно, было бы ужасно неправильным, так как существует множество функций, которые не являются безопасными для асинхронного режима, но которые должны быть безопасны для вызова из обработчиков сигналов.
Это оставляет мне два вопроса:
- Я ошибаюсь или это поведение glibc/NPTL действительно опасно сломано? Если да, то такое опасное поведение соответствует?
- Что, по мнению POSIX, должно произойти, если обработчик сигнала вызывается, когда процесс выполняет функцию, которая является точкой отмены?
Изменить: Я почти убедил себя, что любой поток, который является потенциальной целью pthread_cancel
, должен гарантировать, что функции, которые являются точками отмены, никогда не могут быть вызваны из обработчика сигнала в этом контексте потока
С одной стороны, любой обработчик сигнала, который может быть вызван в потоке, который может быть отменен и который использует любые функции aync-cancel-unsafe , должен отключать отмену перед вызовом любой функции, которая является отменой точка. Это связано с тем, что с точки зрения кода, прерванного сигналом, любое такое аннулирование будет эквивалентно асинхронному аннулированию. С другой стороны, обработчик сигнала не может отключать отмену, если только код, который будет запущен при вызове обработчика сигнала, использует только функции с поддержкой асинхронного сигнала, поскольку pthread_setcancelstate
не является асинхронным сигналом -safe.