|
| From: | James Knight |
| Subject: | Re: Weak references & GC |
| Date: | Wed, 19 Feb 2003 18:06:41 -0500 |
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 little confusion),
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 didn't.
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 other reason.
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?
James
| [Prev in Thread] | Current Thread | [Next in Thread] |