Re: NSDecrementExtraRefCountWasZero

[Andreas Fink]

> On 3 Dec 2017, at 11:46, David Chisnall <theraven@sucs.org> wrote:
> 
> On 30 Nov 2017, at 08:52, Richard Frith-Macdonald 
> <richard.frith-macdonald@theengagehub.com> wrote:
>> 
>> 
>> 
>>> On 29 Nov 2017, at 12:43, David Chisnall <David.Chisnall@cl.cam.ac.uk> 
>>> wrote:
>>> 
>>> Hello the list,
>>> 
>>> In trying to reduce lock contention for deallocation, I took a bit from the 
>>> reference count to indicate that weak references exist to an object (and 
>>> therefore avoid any serialisation on deallocation).  Unfortunately, when 
>>> Andreas tried testing it, he discovered that this broke 
>>> NSDecrementExtraRefCountWasZero (and, in theory, NSIncrementExtraRefCount, 
>>> though not in a way that’s likely to be observable).
>>> 
>>> On OS X, this function is unavailable in ARC mode and comes with a warning 
>>> that if any code uses ARC then it may give surprising results.
>>> 
>>> Looking in GNUstep, it appears that this is called in only a small number 
>>> of places:
>>> 
>>> - NSObject is using it, but probably should just be calling objc_retain() / 
>>> objc_release() / objc_autorelease() (the runtime will call these directly 
>>> instead of retain / release anyway).  NSProxy, similarly, should simply be 
>>> calling the relevant functions.
>>> 
>>> - A few classes are calling it to avoid deallocation of objects that are in 
>>> a table for reuse.It’s also not clear whether this is still a win: we’ll 
>>> get more cache contention from refcount manipulations if the objects are 
>>> small, such as NSIndexPath (though it is required for correctness in a few 
>>> cases, such as NSConnection).  In these cases, if the runtime supports ARC 
>>> then we can simply use a strong-to-weak NSHashTable and get rid of most of 
>>> this logic.
>> 
>> That would be good ... at some point it would be great if the core libraries 
>> could make use of ARC.
> 
> This should be fairly easy now, but only if we’re willing to drop support for 
> GCC - it’s very difficult to maintain code that can compile as both ARC and 
> non-ARC.


Which raises the question on how many people use Objective C and still use GCC?
If you use ObjectiveC 2.0 features such as automatic properties or ARC, you for 
sure will use clang. GCC is a real deal breaker there.
In my project, ARC made a lot of stuff a lot simpler to code and avoided a lot 
of human errors. ARC saves your there.

I'm not sure who else uses GNUStep-base in what scenario and if supporting GCC 
is still kind of a important thing to keep around or not.