[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: macros

From: David Relson
Subject: Re: macros
Date: Fri, 23 Feb 2001 11:34:26 -0500

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 Relson                   Osage Software Systems, Inc.
address@hidden       Ann Arbor, MI 48103
www.osagesoftware.com          tel:  734.821.8800

reply via email to

[Prev in Thread] Current Thread [Next in Thread]