POSIX取消点如何performance?

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

我疯了,还是他们的执行真的这个破? 如果是这样,POSIX是否允许这种破坏的行为(这似乎使取消完全无法使用,除非你手动推迟),还是他们公然忽略POSIX?

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

Solutions Collecting From Web of "POSIX取消点如何performance?"

标准的下一段中是否澄清了这一点:

但是,如果线程在取消点处挂起,并且在取消请求被执行之前发生了它所等待的事件,则不指定取消请求是否被执行,取消请求是否保持挂起,线程恢复正常执行。

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