The system is not aware of responsibility at all. By the time memory management happens, all concept of local variables has disappeared. The system cannot know, and does not care, what variables are "responsible" for an object. All it cares about is properly balanced retains and releases.
Perhaps I wasn't clear enough in my statement as that was what I was trying to get across - if it's only been retained once it will only take one release message to trigger dealloc. As the author stated in his first post, by retaining link, it works as expected which would lead me to believe that link is the result of a convenience method and is consequently autorelease. If that is the issue then yes, he *must* retain it if he expects it to stick around.
This is very wrongheaded. Any code which requires you to retain an object being passed as a parameter to prevent it from being deallocated by another thread is completely broken. So broken that you cannot save it. Retaining at the beginning of a method and releasing at the end *will not save you* in all circumstances. If a second thread can destroy an object in the middle of your method, it can very well destroy it at the beginning before your code has a chance to retain the thing. This is almost certainly not happening in the case in question, because the Cocoa code is almost certainly not utterly broken as this behavior would imply. If it *is* utterly broken in this way, then you cannot fix it with band-aids such as you describe. All you can do is file a bug and avoid using this method at all costs.
In all likelihood this isn't a framework issue and an explanation of locking is very much overkill for what's going on (better architecture, on the other hand...)
Absolutely false. Never do this. If you find yourself doing this then it means you've either horribly misunderstood something or you've encountered a severe bug. The correct course of action is to either correct the misunderstanding or correct the bug, not to wrap all of your methods in retain/release calls.
People new to the concepts of memory management tend to think of balancing retain/release as just something you need to do at init and dealloc which is, sometimes, quite correct. Autorelease makes that slightly more complicated and so I've found this to be a solid defensive practice for individuals who are starting out.
Sounds like you may be confusing -release with -dealloc.
Yes, it's early here (for me).
It's true that objects may be sent -release from other threads. But that doesn'tmatter unless the release results in deallocation of the object. And if that happens you have a severe bug which you must fix.
If you are not retaining the object anywhere - explicitly claiming responsibility for it's continued existence, it is not a severe bug - it is behaving as expected. While a deeper understanding of what's going on will naturally leader to code that is arguably better in almost every way (<insert daft punk lyrics here>) you cannot damage yourself by being too cautious with retain/release.
I have never wrapped any methods in retain/release calls as you described. I've never seen code that does it, and I've never even *heard* of anyone doing it until now. Ask yourself this: do you do [self retain] at the beginning of a method and [self release] at the end? If not, why not? Self is just a parameter like any other. It gets no special treatment (aside from being used to make decisions during the dispatch process). If what you're saying is correct, you must also do [self retain] and [self release] at the beginning and end of every single method you ever write. I hope that this is self-evidently absurd.
As I mentioned above, if one cannot distinguish whether an object is autoreleased or not and one is using mailing lists as an alternative to documentation and/or real debugging then one is perhaps best served by the most defensive code possible such that the flow of logic in the application's architecture is clear and the details of memory management optimizations are left as an exercise for later. As the frameworks progress, memory management is quickly becoming an anachronistic chapter in the long life of Cocoa and in four years I do not expect that we'll be having this discussion.
-rob.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
