On Tue, Mar 3, 2009 at 4:30 PM, Quincey Morris <quinceymor...@earthlink.net> wrote: > On Mar 3, 2009, at 12:50, Nick Zitzmann wrote: >> It doesn't seem to be documented, but I think it will return nil only if >> (1) there was not enough contiguous RAM in the program's VM space to >> allocate the object, or (2) there was, but the user has run out of disk >> space for swap files. But if this happens, the program is pretty much >> screwed anyway, because it's going to crash. > > Yes, I'm aware of the "is pretty much screwed" scenario, but I think there > are in fact some recoverable scenarios. One involves a sequence of very > large (valid) allocations gobbling up VM space so that it becomes impossible > to create a humbler NS... object of some kind. If the application doesn't > crash right away, returning nil (or NO) back through the sequence could > release all the memory and allow the application to continue with an error > message. > > Another scenario is a memory-limited environment like the iPhone.
In either environment, once allocations start to fail for any reason, you are doomed. Recovery is possible, nay reasonable, if you control all of the code in the process. But you don't, and you can bet that Cocoa is *not* written with an eye toward gracefully recovering when malloc() begins to return NULL. You can try to recover from an allocation error, but what if the first NULL allocation happens inside Cocoa code somewhere? If you're lucky it'll end up trying to insert it into a collection or something similar, trigger an assert, and throw an exception. If you're unlucky, the NULL allocation will happen while trying to resize an NSDictionary's hash table and you'll be set up for a crash. Even if you could trap it and recover gracefully by dumping a large allocation, multithreading means that you still have a window of opportunity in between the failure and the allocation dumping where other threads will see allocation failures too. And again, these can happen deep in Cocoa code where you have no chance to survive. Realistically, unless you're a pure libc program, the only way to deal with out-of-memory situations is to detect it in advance and free up memory *before* the allocations begin to fail, the way the iPhone frameworks do it. Mike _______________________________________________ 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
