Queue cleanup

[John Nagle]

On 8/28/2010 5:42 AM, Aahz wrote:
> In article<4c78572c$0$28655$c3e8da3 at news.astraweb.com>,
> Steven D'Aprano<steve at REMOVE-THIS-cybersource.com.au>  wrote:
>> On Fri, 27 Aug 2010 09:16:52 -0700, Aahz wrote:
>>> In article<mailman.1967.1281549328.1673.python-list at python.org>, MRAB
>>> <python at 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