Re: NSApplication delegate not released on quit?
Re: NSApplication delegate not released on quit?
- Subject: Re: NSApplication delegate not released on quit?
- From: Sherm Pendley <email@hidden>
- Date: Sat, 14 Jun 2003 00:38:18 -0400
On Friday, June 13, 2003, at 11:22 PM, Greg Hurrell wrote:
As programmers, we are taught basic rules like:
We are taught basic rules and generalizations as students, because when
we are students, we lack the experience and judgment that are needed to
do more than follow those rules as given. As time goes by, however, we
are expected to learn that there are exceptions to every rule, and how
to identify those exceptions.
- balance each malloc() with a free();
- send a release for every alloc/copy etc;
That's important to do while your program is running, because you need
to manage the individual objects that you're creating and using within
your program's allocated memory. If you don't your program's heap will
continuously grow in size.
However, what we're talking about is not a continuously running program.
We're talking about a situation where the entire heap - the entire
memory that's been allocated to your program in fact, not just its
heap - will be returned to the OS in a few microseconds anyway. In that
case, the management of smaller blocks of memory within the larger -
i.e. of individual memory blocks within the heap - is no longer relevant.
Basically it all boils down to symmetry, and cleaning up after yourself.
The kind of cleaning you're referring to is like polishing the bathroom
fixtures in a building that's scheduled to be demolished in an hour.
Everyone knows that it's a good idea to keep one's bathroom clean, but
it's possible to follow that basic rule to the point of absurdity.
Here, clearly, AppKit (or something else) is at fault. In this case it
looks like NSApp is retaining its delegate and never releasing it, so
it's breaking the code.
A programmer who makes the quite reasonable assumption that NSApp will
release at dealloc time the things it previously retained, will be
bitten by this bug.
I'm making no such assumption. What I'm relying on is the
well-documented and predictable behavior of any modern protected-memory
OS, Mac OS X included. The OS keeps track of what blocks of memory have
been allocated to a program, and when that program exits, it marks those
blocks as free for other programs to use. The OS doesn't know or care
anything about retain counts or malloc; at that point, memory management
at the level of individual objects is no longer relevant.
What if the code is ever ported to a platform where the (correct)
behaviour is maintained? Or to a platform where the OS doesn't do the
cleanup of leaked resources?
What I'm relying on *is* the correct behavior. Any OS that doesn't
reclaim the memory previously allocated to a program when that program
exits is either a museum piece, badly broken, or an extremely
mission-specific special case. I'm not concerned with the first two, and
I'm prepared to deal with this and any other quirks I encounter when
porting to the third.
And if it were corrected
It *was* corrected. Once upon a time, in classic MacOS and DOS-based
versions of Windows, it was possible to allocate memory that didn't get
returned to the OS until it was explicitly released by your code. If
your program crashed, or you forgot to release that memory on exit, it
was basically inaccessible until the next reboot. Thankfully, that sort
of thing is no longer possible.
sherm--
UNIX: Where /sbin/init is Job 1.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.