[Python-3000] Delayed reference counting idea
barry at python.org
Tue Sep 19 16:53:23 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
More information about the Python-3000