Re: macros

[Richard Frith-Macdonald]

On Friday, February 23, 2001, at 04:06 PM, David Relson wrote:

> At 10:38 AM 2/23/01, Helge Hess wrote: 
> >David Relson wrote: 
> > > The macros have different definitions depending on the environment.  I 
> > > don't recall all the particulars, but I remember seeing one set of 
> > > definitions for garbage collection and another set of autorelease pools. 
> > 
> >Exactly. GC was the initial reason to introduce the macros. 
> > 
> > > While looking at the macros and their usage, I did notice an oddity:  In 
> > > approx 6 modules, both AUTORELEASE and RETAIN are used.  For example in 
> > > NSTimeZone.m, the following lines appear: 
> > > 
> > >          zone = AUTORELEASE(RETAIN(defaultTimeZone)); 
> > >          zone = AUTORELEASE(RETAIN(systemTimeZone)); 
> > > 
> > > These seem really odd. 
> > 
> >No, this isn't odd at all. This would be odd and a NOOP: 
> > 
> >   RELEASE(RETAIN(defaultTimeZone)); 
> > 
> >AUTORELEASE ensures that the object will be life in the current 
> >execution context (method/return value) / autoreleasepool transaction. 
>  
> I assert that there's no reason for the  
> AUTORELEASE(RETAIN(defaultTimeZone)).  Ensuring the existence of the object  
> is good, but this doesn't do it. For simplicity let's assume the object is  
> only used once: 
>  
> Let's think about what happens if neither AUTORELEASE nor RETAIN is  
> used.  In this case the defaultTimeZone is simply returned to the user  
> program.  If the user program doesn't release it, all is good.  If the user  
> program releases it, then the object will get deallocated, which is wrong. 
>  
> If instead, we have AUTORELEASE(RETAIN()) and the user program releases it  
> the object will be deallocated and, when the program gets to releasing the  
> autorelease pool it will attempt to release a deallocated object. 
>  
> In both cases, there's trouble if the user program releases the  
> defaultTimeZone.  The AUTORELEASE(RETAIN()) does not ensure safety. 

Helge is quite correct ...

You are not describing the case that the code is there to protect -
any code that releases an object it doesn't own is in error. 

The actual case of concern is where one thread calls 'defaultTimeZone' and
another thread calls 'setDefaultTimeZone:'.  If the autorelease was not used,
then the call to setDefaultTimeZone: could cause the actual default timezone
object to be deallocated before the first thread has time to retain it.

With the autorelease, the problem does not exist.

> > > First, using both RETAIN and AUTORELEASE gives an 
> > > expensive NOP - their effects cancel one another (in an involved, 
> > > time-consuming manner).  Second, with NextStep it was considered a 
> > > mistake 
> > > to call autorelease twice for the same object.  Tracing through the code, 
> > > I 
> > > found 3 occurrences of the defaultTimeZone in the autorelease pool. 
> > 
> >You can call autorelease 100 times and it's still not a mistake, neither 
> >on NeXTstep (with Foundation) nor on GNUstep - as long as it happens 
> >balanced. 
>  
> True, you CAN autorelease many times.  NeXTSTEP also has a mechanism for  
> checking for double autoreleased objects, +[NSAutoreleasePool  
> (NSAutoreleasePoolDebugging) enableDoubleReleaseCheck:(BOO)enable].  I  
> assert that this mechanism wouldn't have been implemented if it wasn't 
> useful. 

The method name is misleading ... it actually checks for an imbalance of
retain/release/autorelease calls - so if a 'final' release occurs, such that
deaalloc woudld be called, and the object is still registered one or more
times in an autorelease pool, the system can raise an exception to tell you
that you must have got things wrong.  It's nothing to do with 'double'
autoreleasing, it's realy an 'extra' release/autorelease check.