Что произойдет, если будет вызван обработчик сигнала а в точке отмены?

Предположим, приложение заблокировано в точке отмены, например чтение , и сигнал получен и обработчик сигнала вызван. Glibc / NPTL реализует точки отмены, разрешая асинхронную отмену на время системного вызова, поэтому, насколько я могу судить, асинхронная отмена будет действовать в течение всего времени обработки сигнала. Это, конечно, было бы ужасно неправильным, поскольку существует множество функций, которые не являются безопасными для асинхронной отмены, но которые необходимо безопасно вызывать из обработчиков сигналов.

Это оставляет меня с двумя вопросами:

  • Я неправильно или поведение glibc / NPTL действительно так опасно нарушено? Если да, соответствует ли такое опасное поведение?
  • Что, согласно POSIX, должно произойти, если обработчик сигнала будет вызван, когда процесс выполняет функцию, которая является точкой отмены?

Изменить: I Я почти убедился, что любой поток, который является потенциальной целью pthread_cancel , должен гарантировать, что функции, которые являются точками отмены, никогда не могут быть вызваны из обработчика сигналов в контексте этого потока:

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

10
задан R.. 23 March 2011 в 17:46
поделиться