Re: Allocating too much memory kills my App rather than returning NULL
Re: Allocating too much memory kills my App rather than returning NULL
- Subject: Re: Allocating too much memory kills my App rather than returning NULL
- From: Quincey Morris <email@hidden>
- Date: Fri, 11 Nov 2011 00:21:36 -0800
On Nov 10, 2011, at 23:14 , Don Quixote de la Mancha wrote:
> I implemented both the app delegate and view controller memory
> warnings, then set breakpoints at both of them. The breakpoints don't
> get hit.
You missed the point of the comments made much earlier in the thread. The breakpoints won't get hit if there's no opportunity for the methods containing them to be dispatched. In the case of the warnings, they're dispatched from the main event loop. Did you code your app so that it returned to the main event loop after each allocation, allowing the memory warning to be dispatched before trying the next allocation?
> As someone else in this thread pointed out, that would be a race
> condition. Even if the system responded with a reasonable amount,
> some other process might allocate enough memory that that amount is no
> longer valid.
>
> The only way to do find out how much memory can be allocated without a
> race condition is to actually try the allocation, then have it fail if
> there isn't enough memory available.
And you don't see the inconsistency between the above 2 paragraphs? If you want to think in terms of race conditions (though that wasn't what I was talking about, but let's use your frame of reference), actually trying the allocation in an inherently multi-threaded environment is itself a race condition. Of course, it's not a race condition for the allocation (which can be assumed atomic), but it is a race condition for the algorithm within which the allocation fits. The atomicity of a single allocation buys you nothing in these circumstances.
> What I am really, really concerned about though is that the iOS is
> inherently unreliable. Killing off processes that ask for too much
> memory doesn't make a system stable. It causes loss of end-user data,
> and makes me loo bad as a developer.
>
> I've done a lot of embedded and device driver programming. If you
> allocate too much memory in those environments, the OS can't kill your
> task, the whole machine will crash.
But this *isn't* either of those environments, nor yet a Mac-like environment. This is a different environment, one in which your habitual assumptions do *not* hold true. In a loose rhetorical sense, the memory environment of iOS *is* inherently unreliable -- that's the point, that's why you have to approach iOS app design differently.
> Instead what one does is back out gracefully from resource allocation
> failures. There are many, many ways to do that. I have already
> implemented the code to back out from allocation failure in Warp Life.
> It works correctly on the Simulator - that is, on Mac OS X.
>
> I have filed a Radar bug with a minimal test case, but Apple has not
> yet responded. It usually takes them a while.
>
> There are many other reasons to allocate memory other than to set up a
> game playing field. There are lots of other kinds of resources other
> than memory as well. If we cannot count on the iOS to let us know
> when resource allocation fails, we are lost.
I repeat the assertion I made previously. iOS *does* let you know when resource allocation fails. It didn't kill your app because resource allocation failed. (We don't even know if resource allocation failed or not.) It killed your app because it was ill-behaved, in iOS terms.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden