Iphone iOS-移植C程序：在NSOperation作业中调用pthread_exit（）

我正在尝试将一个C控制台程序移植到iPhone上。我已将所有代码导入到我的项目中，当用户单击UI上的按钮时，我将在NSO操作中调用它的main（）

无论如何，这个程序很复杂，并且创建了许多自己的线程。该程序也多次调用“exit（）”——这会使整个iPhone应用程序崩溃，但我真的希望用户能够重新启动C程序，如果它这样做的话

我一直在清理这些退出条件，并且在C程序创建的一些子线程中使用了pthread_exit（）。但是，当我在从NSOperation对象创建的线程中调用pthread_exit（）时，应用程序的主线程收到SIGABRT信号，整个应用程序崩溃

我对形势的评估正确吗？我不熟悉iOS编程，所以这个信号可能来自其他地方。。。如果我是对的，那么最好的解决办法是什么

（哦，关于使用“return 0”退出这个NSOperation线程：我想退出的条件嵌套在C程序函数的深处，我想尽量避免改变程序的结构，因为它已经非常复杂了）

---

提前感谢您的帮助

NSOperationQueue

在GCD队列上执行其操作。当这些线程在pthread上执行作业时，这些线程是GCD私有的，不允许您使用pthreadapi修改或退出它们。有关于的文档，其中明确说明哪些pthread函数是允许的，哪些不是

要解决您的问题，您可能不应该让您的pthread代码在

NSOperationQueue

上运行，而应该在您为此创建的新POSIX线程上运行。

不要杀死您的pthread，让它们自然退出。同时，

退出

！=<代码>线程退出。作者在调用

exit

时显然没有考虑清理。因此，通过终止线程，您实际上是在吞下致命错误

如果它不能导致未定义的行为，或其他令人讨厌的事情，如泄漏或死锁，那将是一个奇迹

---

简言之，图书馆被滥用了。如果要继续执行，则应优雅地处理错误。这可能需要做很多工作。

这是真的，虽然在某些情况下我有点不愿意逃避责任，但我正试图谨慎使用这些工具。我还没有准备好重新设计原始程序，但我确实想避免这些问题。我目前使用的策略是：我使用调试器查看哪些线程在执行C程序一次后没有被清理。然后，我在原始线程完成后设置一个标志，它会触发一些正在运行的循环中的中断。它可以工作，可能会有一些内存泄漏，因为这些循环中的一些从未打算结束。我还在执行后重置全局变量。到目前为止，这一切似乎都很有效，但是你对发现和清理危险情况有什么建议吗？哦，我还为原始的exit（）方法做了一个包装。如果它试图用1退出，我实际上会让它退出（我选择从中恢复的特殊情况除外），但如果它用0退出，我假设我可以继续程序以再次运行程序。。。它不是完美的，但我正在朝着它努力。好吧，如果你想试着绕过问题，只攻击你证明存在的东西（与理想相反），那么你的exit/pthread_exit调用可能只是断言处理程序——然后对你的程序进行大量测试。当你点击断言时，找出如何优雅地退出上下文或线程我真的不知道你所面临的程序的复杂性，或者你执行了多少。但听起来你也在尝试在多线程上下文中使用单线程程序，或者重构并重新初始化可重入执行，这可能是一个巨大的PITA=\我想说的是，我正在尝试移植iPerf，但不是为了在App Store或任何东西上发布。它创建了一堆线程和其他东西，但它确实已经编写了一些清理内容。iPerf的一个重要部分是能够使用Control-C取消程序；但要让它在iPhone上正常工作无疑是一个巨大的痛苦。我认为我已经安全地处理了正常和取消退出条件，但还没有处理错误条件。我正在做大量的调试，以确保我得到了正确的结果，但是有很多代码。。所以我不太确定。