Как должны вести себя точки отмены POSIX?

Question

Я смотрел на реализацию точек отмены в glibc / nptl и сравнивал ее с POSIX, и, если я не ошибаюсь, это совершенно неправильно. Используемая базовая модель:

int oldtype = LIBC_ASYNC_CANCEL(); /* switch to asynchronous cancellation mode */
int result = INLINE_SYSCALL(...);
LIBC_CANCEL_RESET(oldtype);

Согласно POSIX:

Побочные эффекты воздействия на запрос отмены во время приостановки во время вызова функции аналогичны побочным эффектам, которые могут наблюдаться в однопоточной программе, когда вызов функции прерывается сигналом и данная функция возвращает [EINTR]. Любые такие побочные эффекты возникают до вызова обработчиков отмены очистки.

Мое прочтение этого отрывка таково: если я позвоню open, я могу ожидать, что либо будет отменено (вместе со всем моим потоком), прежде чем он не сможет открыть файл, или возвращает действительный дескриптор файла или значения -1 и errno, но никогда не создает новый файловый дескриптор, а затем теряет его в пустоте. С другой стороны, реализация точек отмены в glibc / nptl, по-видимому, допускает состояние гонки, когда запрос отмены происходит сразу после возврата системного вызова, но до того, как произойдет LIBC_CANCEL_RESET.

Я сумасшедший, или их реализация действительно сломана? И если да, то допускает ли POSIX такое неработающее поведение (которое, по-видимому, делает отмену полностью непригодным, если вы не откладываете ее вручную), или они просто нагло игнорируют POSIX?

Если это поведение действительно нарушено, как правильно его реализовать без такого состояния гонки?

Answer 1

Разве это не разъяснено в следующем абзаце стандарта:

Однако, если поток приостановлен в точке отмены и событие, для которого он ожидает, происходит до того, как запрос отмены будетпосле этого не определено, выполняется ли запрос на отмену или запрос на отмену остается в ожидании, и поток возобновляет нормальное выполнение.

Что подразумевает, что это условие гонки является совершенно допустимым поведением.

Answer 2

Это было , которое было признано ошибкой в ​​glibc и исправлено в commit 6fe99352106cf8f244418f3708b3d5928e82e831 .

Текст POSIX недвусмыслен, так как побочные эффекты уже не могли возникнуть в случаеотмены.Текст, цитируемый в ответе cmeerw, о том, что если событие

, для которого оно ожидает, происходит до того, как будет обработан запрос на отмену, не определено, выполняется ли запрос на отмену или остается ли запрос на отменув ожидании, и поток возобновляет нормальное выполнение.

позволяет реализации действовать при отмене, если ожидается событие (например, устройство станет доступным, дескриптор файла станет доступным для чтения и т. д..) уже произошло, но не позволяет этого, если событие уже было использовано или иным образом имело некоторый побочный эффект (например, открытие устройства и выделение дескриптора файла, использование данных из канала или сокета и т. д..).