NSThread 与主线程具有相同的内存权限吗?

发布于 2024-11-18 23:13:46 字数 374 浏览 3 评论 0原文

我正在使用 NSOperationQueue 来管理 iOS 应用程序的一个阶段,该阶段相当长,因此我想异步管理它。在该阶段中,我直接使用 calloc 函数在 C 中分配大数组。 对于big,我指的是一个1024x256的二维浮点数数组和类似的东西。

如果所有内容都驻留在主线程上,而不是应用程序在计算时锁定,但一切正常,如果相反,我将繁重的部分移至 NSInvocableOperation ,那么我会得到许多奇怪的结果,使用调试器有时我会得到控制台中出现一条奇怪的消息,指出

现在没有可用于编程的内存:调用 malloc 不安全

因此我想知道由操作队列管理的线程与主线程相比是否有一些不同的限制,以及如何更好地解决此问题。

I'm using NSOperationQueue to manage a phase of an iOS application which is quite long so I would like to manage it asynchronously. Inside that phase I allocate big arrays in C by using directly calloc functions.
With big I mean a 1024x256 bidimensional array of floats and similar things.

If everything resides on the main thread than the app locks up while computing but everything goes fine, if, instead, I move the heavy part to a NSInvocationOperation then I got many strange results, with debugger sometimes I get a strange message in console stating

No memory available to program now: unsafe to call malloc

so I was wondering if threads managed by an operation queue have some different restrictions compared to main thread, and in case what is better to do to get around this issue.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

无声情话 2024-11-25 23:13:46

据我所知,没有任何限制……但是,您可能会遇到可用 RAM 的极限。由于iOS不支持虚拟内存,因此当内存不足时,它会向其他应用程序发送警告以释放RAM。这可能是你的问题的根源。

使用仪器来分析您正在使用的 RAM 量。如果它超过 20MB 左右,您可能会面临由于内存使用过多而被终止的危险。

There's no restrictions that I know of.. however, you may be hitting the edge of available RAM. Since iOS doesn't do virtual memory, when memory gets low, it'll send a warning to other apps to free up RAM. That may be the source of your issue.

Use instruments to profile how much RAM you're using. If it's more than about 20MB or so, you're probably in danger of being terminated due to excessive memory usage anyway.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文