Re: Retaining a NSURL and retaining its -path
Re: Retaining a NSURL and retaining its -path
- Subject: Re: Retaining a NSURL and retaining its -path
- From: Ken Thomases <email@hidden>
- Date: Sat, 12 Sep 2009 18:56:24 -0500
In addition to what others have already said...
On Sep 12, 2009, at 11:43 AM, John Love wrote:
In my controller, one of my instance variables is a NSURL and I
retain it because I pass it to a 2nd controller.
This sentence seems misguided. If it's an instance variable of the
first controller, then the first controller should retain it because
it's keeping it around. It should have nothing to do with the fact
that you're passing it to a second controller. In fact, thinking
about the second controller and what it needs in terms of memory
management is the wrong thing to do while coding the first
controller. The first controller should worry about what it needs in
terms of object lifetimes and express that, but it should not concern
itself with what anything else needs. Then, the second controller
should have the responsibility for ensuring the desired lifetime for
any object on which it depends. Separation of concerns.
In my second controller, I extract [myURL path] and look at it in a
secondary thread loop and everything works fine.
If you're using multiple threads, it is especially important for the
second controller to carefully manage the lifetimes of objects on
which it depends. It should also be noted that I don't see NSURL
listed among the few thread-safe Cocoa classes, although it may fall
under the Core Foundation rule due to toll-free bridging.
I began to think if I could eliminate that call to [myURL path]
every time through that loop I would save "some" time.
Perhaps true, but probably irrelevant. This is premature
optimization. However, taking the URL's path once before passing it
off to a secondary thread does nicely sidestep the possible thread-
unsafety of NSURL. Of course, as others have pointed out, you have to
retain it while you keep it around.
My first attempt was to pass that NSURL in the same manner and then
place the extracted [myURL path] into an instance variable of the
2nd controller. Okay so far .. and then I assumed that if myURL was
retained in the 1st controller, then "naturally" its NSString -path
was also retained
As others have explained, that's an incorrect assumption.
Furthermore, it shouldn't matter. Why are you taking into
consideration what other code may have or probably has or "naturally"
would have done when writing your own code? Any particular class
should make its own arrangements for what it needs without relying on
other code to have done something "nice" on its behalf.
In particular, if you put the path string into an instance variable,
then the class really should own its instance variables (with a few
documented exceptions like delegates or references which would
introduce cycles).
.. but it crashed with "release message sent to a already released
object" (or something like that). Only when I extracted the -path
*and* retained it before I stored it as an instance variable of the
2nd controller did it work.
First of all, why are you paraphrasing the error you got? Why not
just copy and paste it so you're sure to give us accurate information
so we can give you accurate help?
Second, if that's really the error you got, it doesn't indicate that
you're just failing to retain an object that you need to stick
around. If that were the case, you'd have a problem with sending some
other message (other than -release) to an object that's been
deallocated. The message you're describing indicates that you have
unbalanced retains and releases. Did you perhaps store the URL's path
string into an instance variable without retaining it, but leave code
in your -dealloc to release it?
Also, at what point in your code did the error occur? You should use
the debugger to break on the exception (or -[_NSZombie
methodSignatureForSelector:] when using NSZombie) and report the stack
trace and the lines of your own code involved.
Basic question: if a parent object is retained, why isn't each
sibling component object of that parent retained??
What's a "sibling component object"? To me, that phrase doesn't make
sense and is a symptom of the muddled thinking/understanding that got
you into trouble. You may want to review some of the fundamentals
guides, in addition to the memory management guide.
Regards,
Ken
_______________________________________________
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