[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
--------------------------------------------------------
David Relson Osage Software Systems, Inc.
relson@osagesoftware.com Ann Arbor, MI 48103
www.osagesoftware.com tel: 734.821.8800
- macros, ian . mondragon, 2001/02/22
- Re: macros, Richard Frith-Macdonald, 2001/02/23
- Re: macros, David Relson, 2001/02/23
- Re: macros, Richard Frith-Macdonald, 2001/02/23
- Re: macros, Richard Frith-Macdonald, 2001/02/23
- Re: macros,
David Relson <=
- Re: macros, Richard Frith-Macdonald, 2001/02/23