On Feb 17, 2014, at 5:39 AM, David Chisnall <[email protected]> wrote: > On 17 Feb 2014, at 13:33, Mathias Bauer <[email protected]> wrote: >> in case somebody else is also interested in this: it seems that Apple's >> runtime "protects" the developer by ignoring changes to the retain count as >> soon as the object entered its deallocate method. Wrong decision, IMHO.
The model is that an object that has entered -dealloc is dying, and no amount of retaining will preserve it. Balanced retain/release after -dealloc has started is correct, and does not cause -dealloc to be re-entered. (This is important because it's common for complicated -dealloc methods to cause the object to be innocently retained and released as a side-effect of doing something else.) Unbalanced retain/release after -dealloc has started is an error, and the runtime will complain about it on some platforms. Such complaints are not universal for binary compatibility and performance reasons. > It is likely that this is a side effect of weak reference support. Classes > must notify the runtime when they start deallocation now, so that concurrent > loads of weak references abort the deallocation. Apple's implementation > stores objects' refcounts in a map table, so once the object has entered > deallocation it's likely just a separate path. I wouldn't be surprised if > this is not an active decision at all, however it does make adding cycle > detection to ARC easier... Weak reference support didn't change retain counting. Instead, the behavior of weak references was designed to match the behavior of retain counts during -dealloc. Once you begin -dealloc you are irrevocably dying. Weak references to you are cleared and -retain won't keep you alive. -- Greg Parker [email protected] Runtime Wrangler _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
