[Python-3000] Delayed reference counting idea

Barry Warsaw barry at python.org
Tue Sep 19 16:53:23 CEST 2006

Hash: SHA1

On Sep 19, 2006, at 10:42 AM, Marcin 'Qrczak' Kowalczyk wrote:

> Barry Warsaw <barry at python.org> writes:
>> What worries me is the unpredictability of gc vs. refcounting.  For
>> some class of Python applications it's important that when an object
>> is dereferenced it really goes away right then.  I /like/ reference
>> counting!
> This can be solved by explicit freeing of objects whose cleanup must
> be performed deterministically.
> Lisp has UNWIND-PROTECT and type-specific macros like WITH-OPEN-FILE.
> C# has 'using' keyword. Python has 'with' which can be used for that.

I don't see how that helps.  I can remove all references to the  
object but I still have to wait until gc runs to free it.  Can you  
explain your idea in more detail?

> Reference counting is inefficient, doesn't by itself handle cycles,
> and is impractical to combine with threads which run in parallel. The
> general consensus of modern language implementations is that a tracing
> GC is the future.
> I admit that implementing a good GC is hard. It's quite hard to make
> it incremental, and it's hard to avoid stopping all threads during GC
> (but it's easier to allow threads to run in parallel between GCs, with
> no need of forced synchronization each time a reference to an object
> is created).

I just think that it's important to remember that there are use cases  
that reference counting solves.  GC and refcounting both have their  
pros and cons.  I tend to think that Python's current refcounting +  
cyclic gc is the devil we know, so unless there is a clear, proven  
better way I'm not eager to change it.

- -Barry

Version: GnuPG v1.4.5 (Darwin)


More information about the Python-3000 mailing list