Re: Autorelease/Retain/Release
Re: Autorelease/Retain/Release
- Subject: Re: Autorelease/Retain/Release
- From: Bill Bumgarner <email@hidden>
- Date: Wed, 25 Jul 2007 09:00:02 -0700
On Jul 24, 2007, at 8:22 PM, Charlton Wilbur wrote:
It's not hard to envision an autorelease pool optimization in a
framework where the release message is only sent if there are a
certain number of objects in the pool, though whether it would
actually provide a performance increase is doubtful; and if there's
no Cocoa event loop, such as in a shell tool, there may be a single
autorelease pool that's created at the start of the program and
released at the end; code that uses autorelease, such as classes
that may be called as part of a shell tool or as part of a Cocoa
application shouldn't make assumptions about when the objects are
released, because there's no guarantee in the contract.
This is not "quirkiness"; this is "the contract only guarantees what
the contract actually guarantees."
There is a gem here...
Namely: Do not design classes such that you are assuming that the -
dealloc will be invoked when you think it will be invoked. For bug
or valid reason, it might be delayed.
Specifically: Do not manage scarce resources in -dealloc and, thus,
manage scarce resources through reference counting. It is a bad idea
now and a fatal pattern under GC.
Design your classes such that you know when you are done with the
instances *and you tell them to be done*. At that point, the objects
can release scarce resources (file descriptors, network connections,
and buffers/caches, etc).
Under retain/release/autorelease, lumping cleanup logic into -dealloc
and, thus, piggy backing it on retain counts will lead to some very
nasty problems and bugs that are a total pain to debug.
- it naturally leads to order dependencies on object graph tear down.
In and of itself, this isn't necessarily evil. But it is very bad to
lump order dependencies into a mechanism that is inherently non-
ordered -- as soon as an object falls in an autorelease pool, your
carefully constructed, and very fragile, order dependency just got
broken.
- simple memory leaks -- very annoying, but not generally immediately
fatal -- become much more problematic as scarce resources are not
released when you expect them to be released. "no more file
descriptors" often translates to "user cannot save data".
- similarly, leaked objects may no longer be visible on screen, but
may be still connected into the application via notifications or other
mechanisms and, thus, may impact the user experience or the user's
data in what seems to be highly mysterious ways.
- it can lead to cleanup logic being executed on the wrong thread. If
an object falls into an autorelease pool at an unexpected time, it
will be -dealloc'd on whatever thread's pool it happens to be in.
That can easily be fatal for certain kinds of resources that really
want to only ever be touched from one thread.
None of this is conjecture. These are all failure modes that I have
repeatedly run into in various bodies of code (Xcode, for example).
Finally, there is a forward looking reasons for not lumping scarce
resource cleanup into -dealloc and, thus, overriding the memory
management specific reference counting scheme with additional
responsibilities.
Namely: Garbage Collection.
Any logic related to retain/release/autorelease and order dependencies
of -dealloc will be a complete bear to deal with under GC. GC, by
its very definition, entirely eliminates retain/release/autorelease.
As that implies, any logic tied to retain counts will no longer work.
b.bum
(And if you are using -retainCount in production code, well... just
don't. Please. Do not do that.)
_______________________________________________
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