Objective-C ARC和longjmp

无论是否使用 ARC 都不重要；任何 setjmp/longjmp 跳过任何系统框架代码帧将导致未定义的行为（与不可恢复的异常处理原因相同）。

所以，是的，这段代码可能会泄漏。 因为它取决于编译器是否在该块中发出 retain/ release 同时已经放置好位置。也可能因为编译器是否发出 retain/ release 会受到优化级别和版本的影响。

longjmp 仅取消 Lua 的内部，并且永远不会跨任何系统代码，除了 Lua 源代码（它是可感知的）和我的入口点（我希望它们是可感知的）。

这很有帮助。只要您构造入口点，使其 永远 不混合 Lua 跳跃范围的系统范围，就可以了。 我建议在必须管理此问题的源文件中关闭 ARC（当然，将 ObjC->Lua 接口放入封装良好的实现位中，以便代码的其余部分可以保持 ARC 干净）。

但要考虑到隐藏风险：

for(id x in anArray) {
    ... lua call that causes longjmp ...
}

上述代码将导致 lua 跳过系统代码。枚举方法 enumerateWithBlock:, KVO, 通知处理程序等也是如此。

您将不得不非常 非常 仔细地考虑由从 Lua 调用到您的代码触发的每个潜在堆栈触发器。如果该调用触发了系统的任何自动化行为，然后调用了可触发 longjmp 的 Lua API，则所有投注均作废。

longjmp() 可能会导致 ARC 崩溃或者泄漏。调整代码以确保 longjmp() 和 ARC 不发生冲突是困难的。

如果 longjmp() 仅用于处理致命错误路径，并且你希望在响应时停止进程，那么你可能可以忽略该问题。这是 ARC 对 C++/ObjC 异常的默认处理方式。当异常被抛出时，ARC 代码会泄露。虽然有一个编译器选项可以启用异常的清理代码，但这会影响性能。

如果 longjmp() 不是一个终止进程的错误，那么你最好在任何可能被 longjmp() 调用跳过的代码中关闭 ARC。