On May 7, 2009, at 12:05 PM, Marcel Weiher wrote:
On May 7, 2009, at 9:43 , Jeff Johnson wrote:
You misunderstand my argument. I'm not claiming that autorelease
provides some magical guarantee.
Actually, you were initially claiming that there was such a
guarantee, and misquoting the docs to 'prove' your point.
The memory management docs tell you what you should do, but nothing in
Objective-C or Cocoa requires you to follow them. You could write
leaks and overreleases all over the place if you want. (Or even if you
don't want.) So when I cite the docs, I'm talking about what you
should do, not offering any absolute guarantees. There are no absolute
guarantees, except what's in the API -- and sometimes not even then. ;-)
I'm claiming that you ought to write your code to provide the
guarantee. So, for example, don't wrap delegate callbacks in
autorelease pools. There's no need to 'clean up' after your
delegate, as you say. This is a not only a misapplication of memory
management responsibility, but it can lead to unintended and very
bad side effects.
That's an, er, interesting opinion.
Furthermore, I think you can count on Apple to not do anything like
that (and if they do, it's a bug they ought to fix). Why do you
think they suggest creating an autorelease pool inside your
NSXMLParser callback rather than just doing it themselves
automatically?
Because they forgot to do it initially, and then when they found
that their memory consumption was out of the ballpark wanted to add
the pools but couldn't because some client code they didn't want to
break was already assuming longer lifetimes than it had any rights
to assume.
That's an, er, interesting opinion.
And yes, the code that I use explicitly runs the runloop, and it is
the code that runs the runloop that both allocates the
NSURLConnection and then cleans up after it checks the flag.
Perfectly safe, perfectly synchronous.
That's not what I was talking about. I was talking about the
possibility that the 'owned' caller manually runs the run loop right
after it calls the delegate callback, so any performSelector: called
by the delegate will be performed after the delegate callback returns
but within the scope of the caller. How do you protect against that?
_______________________________________________
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
