Re: Get error message about registered observers when Object receives dealloc message
Re: Get error message about registered observers when Object receives dealloc message
- Subject: Re: Get error message about registered observers when Object receives dealloc message
- From: Quincey Morris <email@hidden>
- Date: Sat, 29 Aug 2009 13:03:21 -0700
On Aug 29, 2009, at 12:26, Andreas Grosam wrote:
Just to be clear, the code is running on the iPhone, hence there is
no GC. Secondly, there is no issue with release or retain. If I
invoke release from within a dealloc in order to release a certain
object, I have to do it exactly the same way - even when the current
KVO issue has been corrected somehow in my code. So, retain/release
is unrelated to the current problem. The solution to my problem
seems to be to unregister all KVO *before* the object hierarchy gets
deallocated.
No, there's no issue with calling the 'release' and 'retain' methods.
It's an issue of object lifetimes -- what and when. Incidentally,
although GC isn't an iPhone issue now, I can't imagine that GC won't
become available on the iPhone in the next couple of years. (Perhaps
when CPU horsepower and battery life limitations have eased enough.)
If the dealloc method does not directly or indirectly invoke a
method of any object that is currently deallocated, the design
should be safe. But I wouldn't recommend it, because it may become a
problem later when code changes.
Yours may be safe. Mine wasn't, the last time I wrote a non-GC app
(which is nearly 2 years now). I managed to so overload the semantics
of dealloc that I couldn't get my data model to go away. :)
Though, I don't see why this is a *second* problem - IMHO it's just
a concrete reason of the one problem.
It really is just one problem, but I was trying to forestall comments
like, "Well, things would be just fine if Apple didn't place this
arbitrary restriction on unregistering." It's one problem, but it's
larger than just unregistering.
Absolutely. Even when I have a mechanism to tear down an object
hierarchy via a shutdown message, after shutdown has been received,
the object is effectively invalid. If there exists a third object
that holds a reference to this torn down object, problems may occur
since the object became invalid prematurely.
I think you have two ways to approach this. One is ensure that your
design correctly decides when an object is no longer needed, so that
the question of messaging an "invalid" object never arises. The other
is to put the object into a shutdown state, where messaging it is
either harmless or returns an error or throws an exception.
How could this be implemented? When an object gets deallocated it
always previously received release with retain count one or - in
case of GC - the last reference diminished. When this happens, it is
already to late for a notification.
This will probably make you laugh, or worse, but I think in the
hardest cases the best solution will turn out to be ... reference
counting (implemented manually). That is, if the criterion for when a
shared object should free its resources is really as vague as "when no
one wants the object any more", the object could track how many other
objects have registered interest in it, using a pseudo-retain/pseudo-
release messaging protocol.
Think of it this way. An object really has 2 lifetimes -- visibility
and existence. GC (and other factors) take existence mostly outside
your control (aside from housekeeping), but visibility is what you
really care about.
_______________________________________________
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