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: Roland King <email@hidden>
- Date: Sun, 6 Sep 2009 20:46:58 +0800
On 06-Sep-2009, at 2:22 PM, Quincey Morris wrote:
I haven't tried to evaluate the GC side of this under 10.6, but I
can't imagine that the basic rule has (or could be changed) under
GC: that cleanup relating to the relationships between objects needs
to be done prior to entry to 'finalize' instead of during it.
The irony here is that although the dealloc pattern for removing
observers is now reliable, anyone relying on it is going to have to
throw it away as soon as they switch over to GC. (Or worse, that
relying on it is going to tend to lock them out of GC because
switching over is going to require an awkward redesign.)
You made me go read the Snow Leopard note about KVO under GC a few
times, it's repeated at the end of the mail. The way I read that is
that in fact doing it during the finalize method is ok and that lots
of code ended up having finalize methods just for that purpose, so I
would say the same method just discussed would still work, just
implemented in finalize instead of in dealloc.
The note however says that in order to reduce the amount of finalizer
methods written just to do KVO registration removal, the runtime now
does it for you automatically in 10.6. So if you're observing
something and are collected, the observations you registered are
automatically removed. It doesn't say if it works the other way
around, ie if A is observing B and B is collected, whether A's
observation is removed; if it were not, when A is eventually collected
I'm not sure what would happen as A's still outstanding observation on
a non-existant object would be removed. Of course that shouldn't
happen as A should have a reference to B anyway in that case in order
to do KVO teardown the normal way so B should always persist at least
as long as A does. Or even the built-in runtime ability to teardown
your KVO for you must keep a reference to B in order to do that job
so .. it's probably never an issue.
That's my read but I'm way behind the curve on GC in general and don't
totally have the full mental picture I have of retain/release so I
could be a little off base.
With the addition of support for Objective-C garbage collection to
Foundation in Mac OS 10.5 one of the basic rules of key-value
observing (KVO) remained, and still applied to garbage-collected
applications: all invocations of KVO's -
addObserver:forKeyPath:options:context: method must be balanced by
invocations of -removeObserver:forKeyPath: or KVO will leak memory.
(KVO logs when it senses failure to follow this rule but only when
running non-garbage-collected.) The same rule applied to use of KVO's
NSArray batched observer registration methods. This resulted in
situations in which classes of observers had to have -finalize methods
just to do observer deregistration when they otherwise would not have
to. -finalize methods are supposed to be rarer than that. In Mac OS
10.6, explicit removal of observers when they're finalized is now
never necessary. KVO automatically removes observers as they're
collected. Actually, in Mac OS 10.6 all invocations of -[NSObject
(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] and -
[NSArray(NSKeyValueObserverRegistration)
removeObserver:fromObjectsAtIndexes:forKeyPath:] do virtually nothing
when either the receiver or the observer is being finalized (so it's
not very bad for performance to leave them there in applications that
still have to run on Mac OS 10.5).
_______________________________________________
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
_______________________________________________
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