Re: NSXMLParser frees itself on error?
Re: NSXMLParser frees itself on error?
- Subject: Re: NSXMLParser frees itself on error?
- From: Marcel Weiher <email@hidden>
- Date: Thu, 7 May 2009 16:00:13 -0700
On May 7, 2009, at 10:39 , Jeff Johnson wrote:
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.
Well, the docs don't give the callee any guarantees in terms of
lifetime of returned objects, and certainly no way to "tunnel" through
the caller (except for keeping a retain on the object, keeping
ownership). I am now aware that you are of the opinion that there
should be such guarantees, and it is obvious that I won't be able to
change your mind, so we should just let that be.
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.
It's actually somewhat more than an 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?
*I* don't. It is you who wants these sorts of guarantees and
protections. I code in ways that don't assume these sorts of
protections.
Anyway, I have given you the information about how this stuff works.
I understand your opinions on how you feel this stuff should work.
Good luck,
Marcel
_______________________________________________
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