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