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 11:37:45 +0800
On 30-Aug-2009, at 5:53 PM, Roland King wrote:
On 30-Aug-2009, at 17:46, Andreas Grosam <email@hidden>
wrote:
b. The release notes say that it was wrong for this message to
appear "when an object observed by a second object was
deallocated, its deallocation caused the release of the second
object, and the second object correctly unregistered itself as an
observer of the first object at that time due to its own
deallocation". So this sort of thing should be OK.
Nothing is clear here. Do the authors just mean, the exact wording
of the message was not correct, or do they mean there should no
message come up at all - since the code is correct?
The wording clearly implied the error message should not have been
logged and that the code is perfectly correct. I can see no other
way to read it.
It says "correctly unregistered itself" that really says code is ok.
If Singapore ever stops being sold out of snow leopard I'll compile
it and run it and find out.
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.
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.
_______________________________________________
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