POSIX 取消点应该如何表现？答案

【问题标题】：How are POSIX cancellation points supposed to behave?POSIX 取消点应该如何表现？
【发布时间】：2011-05-11 22:09:03
【问题描述】：

我一直在研究 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 值，但永远不要创建一个新的文件描述符然后将其丢失到 void 中。另一方面，取消点的 glibc/nptl 实现似乎允许在系统调用返回之后但在 LIBC_CANCEL_RESET 发生之前发生取消请求的竞争条件。

我疯了，还是他们的实现真的这么糟糕？如果是这样，POSIX 是否允许这种破坏行为（这似乎会使取消完全无法使用，除非您手动推迟它），还是他们只是公然无视 POSIX？

如果这种行为实际上被破坏了，那么在没有这种竞争条件的情况下实现它的正确方法是什么？

【问题讨论】：

标签： c linux pthreads posix glibc

【解决方案1】：

这不是在标准的下一段中阐明了吗：

但是，如果线程在取消点和事件它正在等待发生在取消请求被执行，它未指定是否取消请求被执行或是否取消请求仍然挂起，线程恢复正常执行。

这意味着这种竞争条件是完全合法的行为。

【讨论】：

如何编写具有这种荒谬行为的健壮程序？看来您要么必须将每次调用 open（和其他可以分配资源的取消点）都用代码来禁用取消，保持取消始终禁用并定期手动调用 pthread_trycancel，或者想出一些方法来搜索并释放此类资源（对于文件描述符，可以遍历所有值，但在没有一些重型锁的线程应用程序中这样做非常危险）。
mmh，我读到该线程可能还没有被取消，应该在下一个取消点取消（在这种情况下，取消点需要操作系统支持，并且可能在R.. 在大多数操作系统上所说的方式）。
@ninjaj：我认为 cmeerw 可能是正确的。这段话是说，如果（例如）线程被挂起，等待open 返回，但open 已经完成了它的工作，实现可以允许取消发生或让它挂起。
经过多次讨论，包括请求和接收来自 Austin Group（负责 POSIX）的解释，我不再认为这个答案是正确的。 “它正在等待的事件”不是“打开文件”，而是在打开文件之前必须发生的任何事件（例如打开另一个和一个 fifo）。 “恢复正常执行”将打开文件；取消操作需要确保副作用与EINTR 上的副作用相匹配（即文件未打开）。
有关 Austin Group 的参考资料，请参阅austingroupbugs.net/view.php?id=614 和相关问题。

【解决方案2】：

这是acknowledged as a bug in glibc 并在commit 6fe99352106cf8f244418f3708b3d5928e82e831 中修复。

POSIX 文本明确指出在取消的情况下不可能已经发生副作用。 cmeerw 的回答中引用的文字，如果

它正在等待的事件在取消请求被执行之前发生，未指定取消请求是否被执行或取消请求是否保持挂起并且线程恢复正常执行。

如果正在等待的事件（例如设备变得可用，文件描述符变得可读等）已经发生，则允许实现对取消采取行动，但如果事件已经使用或有一些副作用（例如打开设备并分配文件描述符、使用管道或套接字中的数据等）。

【讨论】：