[Python-3000] Delayed reference counting idea

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRRAEa3EjvBPtnXfVAQIpyAQArWHs0j+yJs5raS4EQgj/v1NXYOqzXLAn
eM5eWMMTDY6qZgWa2i7DFciO1MZnX6/HAUsRYSc7lHPEWKMbNoCgPQZP46XoX8/w
FYtvuRCdVUlPvTtfZk8ltl/ERXb+vtR4Jtb/dT7+0VxdbGLHvqgMaCrcDXMd2n4C
du4cjV+GZ1k=
=anX9
-----END PGP SIGNATURE-----