[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Weak references & GC
Re: Weak references & GC
Wed, 19 Feb 2003 18:06:41 -0500
On Wednesday, February 19, 2003, at 05:21 AM, Richard Frith-Macdonald
On Wednesday, February 19, 2003, at 06:19 am, James Knight wrote:
Hi, I recently have been hit with some crashing bugs in my app that
uses gnustep with GC, and traced it back to the fact that
NSNotificationCenter uses disguised pointers so that the GC doesn't
keep the referenced objects around. However, when the object
disappears, the observation is not cleared. In non-GC mode it's
clearly the user's responsibility to clear the observation in the
-dealloc method. However, in GC mode, I feel the system should be
doing this for you. The following patch accomplishes this, and does
not affect non-GC mode at all.
I kind of assumed that objects registering themselves as observers
would use the gcFinalize method to remove themselves as observers when
they are garbage collected... like the removal in the dealloc method
where GC is not used.
The ultimate goal of GC is to make it so that it's impossible to ever
have a valid pointer turn into an invalid pointer. Anything we can do
to further that goal is a good thing. When the notification system
decided to use a weak reference, at that point, it has taken
responsibility for making sure that the weak reference doesn't cause
problems. The two options are thus to track the disappearance of the
objects weakly pointed to, or to make the reference a strong one.
While I'm sympathetic to the idea that the system might automatically
remove observer when they are deallocated, this would be a difference
between the GC and non-GC methods of operation (which might lead to a
It isn't any more of a difference than the fact that in GC mode you
don't need a dealloc that releases objects you store in instance
variables. For me, it led to confusion that GNUstep uses weak
references that *don't* automatically go away and instead cause a
segfault, because I'm more used to weak refs as used in Java, where
they do go away for you.
and more importantly, it would be inconsistent/confusing if the
notification system did this but other classes using weak references
I agree. This was only a start, to see what other people thought of the
idea, and get the code out there for discussion.
So ... if we intend to have automatic removal of observers from
notification centers when operating with GC, we should also do the
same for any other occurrences of weak references ...
Yep. If I'm using GC I want to never see an invalid pointer besides nil.
Do you know the answer to my question as to why delegates need to be a
weak reference? I suspect the reason in reference-counting scheme is so
you don't have a circular reference loop that causes them to never be
deallocated, but that isn't a concern with a real GC. However, I don't
know all that much about the topic and may very well be missing some
If delegates can be made non-weakly-referenced in GC mode, I think that
removes pretty much all other cases of weak refs in the libraries?