我正在尝试为C OSX Carbon 多线程应用程序安装“崩溃处理程序”。 在Windows上，我可以轻松使用简单而有效的__try{} __except{} SEH of Windows，效果很好。 （注意这些是无关到C ++异常，这些是较低级别的C构造！）
这与question I asked on SO previously非常相关： 还有older SO question。
答案似乎是在每个代码区域之前使用setjmp（），然后在发生崩溃时使用信号处理程序返回longjmp（）。
但是由于多线程的实现，这是非常重要的！ Windows中的__try {} __except {}习惯用法是线程安全的，Just Works。但显然setjmp不是线程安全的。
那么实现会是什么样子？ 我一直在想我将不得不实现一些线程本地存储。在开始时，我初始化setjmp，将环境状态存储到线程本地缓冲区，然后信号处理程序必须通过查看线程局部区域再次找到环境数据。但是，Google和SO都没有证据表明这是正确的策略，特别是因为setjmp（）被记录为线程不安全。 并且不会线程本地存储需要每个线程注册自己并分配内存（以保存该环境数据），并在线程销毁时释放它？
我希望我能在OSX上创建一个包含所有这些的宏，我的__try __except代码才能正常工作。
那么，如何使用signal和setjmp创建OSX多线程安全崩溃恢复处理程序？
答案 0 :(得分：1)
ReactOS有一个名为PSEH的SEH克隆。 ROS Newsletter #49简要提及了它，你可以看到它是如何在/include/crt/excpt.h，/include/reactos/lib/pseh/pseh2.h等中实现的。有点像一个看起来很混乱的黑客和宏（目前仅限x86）装配，但它的工作原理。
话虽如此，在UNIX上，信号+线程交互是着名的丑陋，所以如果你想要SEH的目的是处理信号......我建议你找一个替代解决方案。
答案 1 :(得分：0)
我使用setjmp / longjmp使用类似的异常处理，我有线程本地存储。对于每个新线程，我将初始化函数称为malloc的本地jmpbuf用于线程。
NB！我从未在多线程环境中对其进行过适当的测试！