[Python-3000] Delayed reference counting idea

[Greg Ewing]

Barry Warsaw wrote:

> It's been a long while since I programmed on the NeXT, so Mac folks  
> here please chime in, but isn't there some Foundation idiom where  
> temporary Objective-C objects didn't need to be explicitly released  
> if their lifetime was exactly the duration of the function in which  
> they were created?

I think you're talking about the autorelease mechanism.
It's a kind of delayed decref, the delay being until
execution reaches some safe place, usually the main event
loop of the application.

It exists because Cocoa mostly manages refcounts on a much
coarser-grained scale than Python. You don't normally
count all the temporary references created by parameters
and local variables, only "major" ones such as references
stored in an instance variable of an object. The problem
then is that an object might get released while in the
middle of executing one or more of its methods, and there
are still references to it in active stack frames. By
delaying the decref until returning to the main loop, all
these references have hopefully gone away by the time
the object gets freed.

You couldn't translate this scheme directly into Python,
because there are various differences in the way refcounts
are used. There's also not really any safe place to do
the delayed decrefs. The interpreter loop is *not* a safe
place, because there can be nested invocations of it,
with C stack frames outside the current one holding
references.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+