On Wed, Nov 19, 2008 at 11:48 PM, Kyle Sluder
<[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 11:38 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>> Seriously, this kind of hysteria does nobody any good. Nothing you do
>> besides explicitly releasing/draining an NSAutoreleasePool instance
>> that you explicitly created is going to drain the current autorelease
>> pool. You cannot make a call that "hits the top of the runloop", as a
>> call is going deeper into the stack by definition, and the top of the
>> runloop is shallower in the stack. If they run a nested runloop then
>> fine, those things nest.
>
> There's a reason that the documentation says "normally guaranteed,"
> not just "guaranteed":
>
> "A received object is normally guaranteed to remain valid within the
> method it was received in (exceptions include multithreaded
> applications and some Distributed Objects situations, although you
> must also take care if you modify the object from which you received
> the object)."
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
Irrelevant. This is talking about objects that you get back from
methods, not objects that you explicitly autorelease yourself.
>> Autorelease is *not* a signal that you no longer need an object.
>> That's what release does. Autorelease is a way to relinquish ownership
>> of an object *without destroying it right away*. The entire reason it
>> exists is so that you can safely and easily return objects to callers.
>> It would be utterly useless as a construct if such objects could
>> disappear at any moment.
>
> We're saying the same things here, I think. The only issue I have is
> that in between returning an object and the caller being invoked --
> barring multithreading -- nothing else can happen, so your "reason" is
> incorrect. Even if objects could disappear after any method call at
> all, that doesn't mean that they could disappear during the return.
That is true but that's not how it actually works. Also there is no
need to bar multithreading. The rules work equally well in a
multithreaded environment.
>> The lifetime of autorelease pools is well defined and highly
>> predictable. It is flat-out impossible for a Cocoa app which is not
>> experiencing some sort of memory smasher or other faulty behavior to
>> destroy an autoreleased object in the same scope in which it was
>> autoreleased, unless there is a very obvious call to destroy an
>> NSAutoreleasePool sitting right there in that code. Please, stop
>> spreading misinformation.
>
> Again, I defer to the documentation. Perhaps it's because I'm working
> a lot with Distributed Objects that I'm being paranoid about object
> lifetimes.
You need to defer to the correct piece of the documentation. The only
reason that the documentation specifies "normally" is because you can
have methods which return objects which are not autoreleased, but
instead return a reference to an internal object or something similar.
To put this as simply as possible, consider the following skeleton:
- (void)method
{
id obj = [... autorelease]
...SOMETHING...
return obj;
}
In any correctly written program, no matter WHAT you put in the
...SOMETHING..., you cannot cause obj to be destroyed. To put it
another way, if obj gets destroyed before reaching the return
statement then you have a serious memory management bug, and shuffling
around the position of the autorelease call will not save you.
What you described simply cannot happen in any correctly written
application. There are *similar* situations where you have to be more
careful, namely when you get a non-owned object back from a method.
For example:
- (void)method
{
id obj = [... foo]
...SOMETHING...
return obj;
}
In this case you certainly can cause obj to be destroyed, depending on
exactly how 'foo' is implemented. For example, a call to -setFoo: may
result in its destruction. But that's not the same thing at all.
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 [EMAIL PROTECTED]
