Re: Memory Management question
Re: Memory Management question
- Subject: Re: Memory Management question
- From: Robert Marini <email@hidden>
- Date: Fri, 26 Dec 2008 13:18:26 -0500
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't
matter 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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