[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:06:08 -0500

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:


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.

> 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

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.



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]