On 8/28/2010 5:42 AM, Aahz wrote:
In article<4c78572c$0$28655$c3e8...@news.astraweb.com>,
Steven D'Aprano<st...@remove-this-cybersource.com.au> wrote:
On Fri, 27 Aug 2010 09:16:52 -0700, Aahz wrote:
In article<mailman.1967.1281549328.1673.python-l...@python.org>, MRAB
<pyt...@mrabarnett.plus.com> wrote:
An object will be available for garbage collection when nothing refers
to it either directly or indirectly. If it's unreferenced then it will
go away.
This isn't actually garbage collection as most people think of it.
Refcounting semantics mean that objects get reaped as soon as nothing
points at them. OTOH, CPython does also have garbage collection to back
up refcounting so that when you have unreferenced object cycles they
don't stay around.
I've repeatedly asked, both here and elsewhere, why reference counting
isn't "real" garbage collection. Nobody has been able to give me a
satisfactory answer. As far as I can tell, it's a bit of pretentiousness
with no basis in objective fact.
You'll notice that I was very careful to qualify my statement with "as
most people think of it". Also, because CPython has two different memory
management mechanisms, refcounting and cycle detection, and the module
that controls cycle detection is called "gc", I think it's simpler to
follow along with the Python docs -- and critically important to remind
people that there are in fact two different systems.
Personally, I'd like to have reference counting only, an enforced
prohibition on loops (backpointers must be weak pointers), RAII,
and reliably ordered finalization.
A big advantage of reference counting is that finalization happens
in the thread that releases the object, and in the correct order.
GC and finalization/destructors do not play well together at all.
Microsoft once tried to get the hard cases to work right. See
"managed C++". Not a happy story.
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
