On 9 Nov 2011, at 17:33, Dave Camp wrote: > This was discussed at a WWDC session a couple of years ago. If your app > attempts to allocate a large block of memory, and the OS cannot get other > processes to give up memory in a timely fashion, your app will be killed. > > It's the reverse of you getting the low memory messages. As you take up more > and more memory, the OS has to send the low memory messages to other apps to > get them to release memory for you. If you allocate memory faster than the OS > can re-claim it from other processes, your app will be terminated.
Maybe you didn't mean it this way, but this makes sound as if the foreground app never gets memory warnings, it's just terminated if it uses too much RAM. This is not true. In general, the opposite is true - other apps that have been suspended are not 'woken up' just to be given warnings - they're just terminated. The foreground app will get warnings, and a short chance to clean up - that's what the warnings are for. Remember, before iOS 4 there were no background apps, but the memory warning mechanism has been around for ever. Again, I /absolutely do not/ think that allocating in a tight loop and waiting for the warnings to find out how much memory you can allocate is a very good strategy. I'm skeptical that it will work at all, given the rate of allocation you'll have and how long it might take you to clean things up, and it's bad from an "OS citizenship" standpoint too. I just want to clear up some potential misinformation on the warnings. Jamie._______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
