I feel compelled to wade in here, to clarify a point. I'll pick on
Luke's comment but there were some other similar ones ...
On Nov 19, 2008, at 15:44, Luke the Hiesterman wrote:
It's simply not true that you have "no idea" when an object will be
autoreleased. If you're on the main thread, you know that it will be
released at the end of the runloop, and you know that your current
method will return to its caller within the current runloop.
Regardless of "main thread", the autoreleased object will be released
*when the current (at the time of the autorelease) pool is popped*.
NOT "will be released at the end of the runloop". (If anything, that
should be "at the end of the event loop", but of course that's still
not correct -- see sentence #1.) Autoreleased objects even on the
main thread do not "survive until an event is finished being handled",
which is another interpretation. I think these come from a warped
combination of the documentation's description of the AppKit having a
pool around event handling, and the release happening when an
autorelease pool is popped.
For example, if the AppKit were to add a pool in the -[NSApplication
sendEvent:] call one usually sees in an event handling backtrace,
autoreleased objects that ended up in that pool would get released
when execution flow got back to -sendEvent:, which is not at long as
the "end of the event loop".
I've had to debug several third party apps over the years which
apparently assumed "the object would live at least until the end of
the current event handling", which were tripped up when the lifetime
was made shorter by a new pool being introduced somewhere. And if
it's an important app, we often can't introduce the pool we wanted to
due to binary compatibility, which means everybody loses if it would
have improved typical app performance.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
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 [EMAIL PROTECTED]
