c++ - 在指定 C++ 异常和 pthread 取消的交互方面有什么进展吗？

Question

最近，GNU C 库使用 DWARF2 展开用于 pthread 取消，因此 C++ 异常和 pthread 取消清理处理程序都通过公共(public)调用框架展开过程调用，该过程在必要时调用自动对象的析构函数。然而，据我所知，仍然没有指定 (POSIX) 线程和 C++ 之间交互的标准，并且可能希望可移植的应用程序应该假设从取消清理上下文中抛出异常与调用 longjmp，并且取消具有非平凡析构函数的实时自动对象的线程也是未定义的行为。

是否有任何正在进行的标准化流程来处理这种交互，或者它是否可以预期在未来很长一段时间内未定义？ C++11 在其线程支持中是否有任何类似于 POSIX 线程取消的概念？

Answer 1

作为包含 WG14 (C)、WG15 (POSIX) 和 WG21 (C++) 的 ISO/IEC SC22 的成员，我可以告诉您快速的答案是否定的，C++ 异常和线程取消不会出现很快就会彼此。 C11 和 C++11 没有提到线程取消，并且在大约十年后的下一个主要标准发布之前，即使不是极不可能，也极不可能认识到它。

较长的答案归结为标准的运作方式。基本上ISO只能规范大家能达成一致的东西，而线程取消的时候大家是不同意的。执行线程必须在每个可取消的系统调用之前转储状态的整个想法违背了现代软件开发的整体精神。它给编译器优化带来了巨大的问题，因为与 C++ 异常抛出不同，线程取消被定义为与调用 thread_terminate(self) 相同，这明确排除了做任何额外的事情(甚至取消处理程序在许多实现中都不能可靠地调用)，并且我不认为线程取消支持者会不同意这是一个糟糕的解决方案。

问题是唯一合适的选择是重新发布带有异步完成变体的 POSIX i/o API。问题在于不同的 POSIX 实现对异步完成的看法非常不同。我的意思是，我们甚至无法就内核等待队列的标准达成一致，因此在实现该标准之前，异步 i/o API 还有很长的路要走。我有一个关于为下一个标准 TC/TR 对内核等待队列进行一些移动的提议，但提议的对象故意非常简单。

我们在 C11/C++11 中尝试做的是让线程 API 始终具有非阻塞版本——其中只有一个 API 不能以非阻塞方式完成，即 thread_join( )(没有 thread_timedjoin())，我计划在获得 Austin 工作组批准后亲自提交勘误表。在所有其他情况下，人们总是可以构建一些东西，它可以轮询效率不高但程序正确的东西。

从长远来看，就我个人而言，我认为有充分的理由按照与 C++ 相似的语义向 C 添加异常处理。你不一定有对象支持(我实际上个人也支持将非虚拟对象添加到 C)，但你会有堆栈展开的 lambda 函数调用的概念。这将使我们能够通过适当定义的机制将诸如线程取消之类的黑客行为形式化。它还让您像编写风一样编写展开，并让旧 C 与新 C 透明地互操作，从而使编写容错 C 变得更加容易和安全。

关于从异常处理中抛出异常，我个人认为我们需要做一些比总是自动调用 terminate() 更好的事情。由于展开可能导致新对象的构造，或者实际上任何其他异常抛出源，我个人非常希望在终止进程之前尽一切合理尝试展开整个堆栈。

因此，简而言之，预计 POSIX 线程取消将继续被视为未定义，并且从长远来看，很有可能它会被弃用，取而代之的是更好的东西。

顺便说一句，通常 POSIX 线程取消在实现之​​间是高度不可移植的，因此任何使用 POSIX 线程取消的代码实际上都依赖于特定于平台的行为，这与使用非 POSIX API 相同。如果您希望代码可移植，请不要使用 POSIX 线程取消。而是使用 select() 或 poll() 包括一个神奇的“请立即停止线程”文件描述符。在我自己的 C++ 代码中，我实际上有一个系统 API 包装器宏，它测试这个神奇的文件描述符并抛出一个特殊的 C++ 异常。这确保了在所有平台(包括 Windows)上的行为相同。