Re: macros

[David Relson]

At 11:26 AM 2/23/01, Richard Frith-Macdonald wrote:

> 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.

Good point.  I hadn't considered setDefaultTimeZone, which clearly creates 
a need for the protection.

> 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.

My recollection is that the error is trapped when autorelease is called, 
not when dealloc is called.  I remember seeing lots of complaints in my 
early days of using the Foundation classes.  However, I'm too lazy to fire 
up an OpenStep machine to check.

Thanks for the explanation.

David



--------------------------------------------------------
David Relson                   Osage Software Systems, Inc.
relson@osagesoftware.com       Ann Arbor, MI 48103
www.osagesoftware.com          tel:  734.821.8800