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 (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
