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, 5 Sep 2009 23:22:33 -0700
On Sep 5, 2009, at 20:37, Roland King wrote:
Following up on this thread from a week ago. Singapore did stop
being sold out of Snow Leopard and I compiled a little test project
under 10.6 to see what happened. Here's what I found.
1) If you recall the original thread, the error message about
objects being deallocated whilst having attached observers was
emitted at the start of the original poster's dealloc method, before
he had a chance to run any code. This is now not the case, the
message is emitted only during the [ super dealloc ] call at the
end. To my mind that's consistent with the release notes which
indicated to me that you may unhook observers (yourself included)
during the dealloc method.
2) As the release notes state, if you exit the dealloc method whilst
you are still observing yourself, you get an error message where you
didn't used to.
What I implemented for this test was my own totally loose
observation protocol. Observers and Observees weren't related in any
way and neither retained the other, I made a number of them in the
test and arranged it such that some Observers were deallocated
before the things they were observing, and some Observees were
deallocated whilst things which were observing them were still
retained elsewhere.
I set up the Observers to unhook their observations on the
(unretained but stored) Observee during their dealloc methods as
normal. The Observee objects also observed their own 'foo' property
and unhooked that observation in their own dealloc method. They also
had another property "canBeObserved" which was YES by default, and
flipped to NO at the start of their dealloc method. The Observer
objects observed both 'foo' and 'canBeObserved'. If canBeObserved
became NO, they removed their observations on both properties of the
observee at that point.
So if an Observee was deallocated whilst Observers were still
observing it, the canBeObserved property was set to NO at the start
of the dealloc, that property change caused any Observer still
observing to unregister the observations, then the Observee stopped
observing itself, then [ super dealloc ] was called.
This appears to work perfectly. I get no error messages about
objects being deallocated whilst they still had registered
observers, which is true, they aren't, during the dealloc of the
Observee all observers get unregistered (self directly, anyone else
via KVO of the canBeObserved property). So I still believe the
original error wasn't really an error, that the message being logged
at the start of the dealloc instead of at the end was a bug which
has been fixed in 10.6 and that it's totally fine to cause observers
to be removed during your own dealloc. By using a canBeObserved
property I'm not relying (as the original poster was) on Observers
being dealloc'ed during the dealloc of the thing they are observing,
which I continue to agree is a poor practice.
Thanks for doing the legwork on this. It all makes sense as you've
laid it out.
And none of this says anything about running Garbage Collected, I
was running only in Retain/Release mode. My reading of the release
notes seems to indicate to me that GC does a lot of this cleanup for
you automatically, which is good as I'm not sure you could use a
similar coding strategy in finalize methods which are called in an
undetermined sequence.
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.)
_______________________________________________
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