Re: Can't get setDelegate to work on NSMenu attached to NSStatusItem
Re: Can't get setDelegate to work on NSMenu attached to NSStatusItem
- Subject: Re: Can't get setDelegate to work on NSMenu attached to NSStatusItem
- From: Michael Ash <email@hidden>
- Date: Wed, 4 Mar 2009 00:11:32 -0500
On Tue, Mar 3, 2009 at 4:30 PM, Quincey Morris
<email@hidden> 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 (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