Queue cleanup

[Paul Rubin]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
> 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.

Well, it's a bit of a subjective matter.  I'd say it's not real gc
because 1) it's unsound (misses reference cycles), and 2) it requires
constant attention from the mutator to incr and decr the reference
counts.  So developing modules for the CPython API means endlessly
finding and fixing refcount bugs that lead to either crashes/security
failures, or memory leaks.  If you program the Java JNI or a typical
Lisp FFI, you'll find that real gc is a lot simpler to use since you
avoid all the refcount maintenance hassles.  You allocate memory and
shut your eyes, and the gc takes care of freeing it when it figures out
that you are done.  Refcounting is basically a form of manual memory
management, while gc is automatic.  

Someone said here recently that as a program gets larger, saying "this
will work as long as we do X every time without fail" becomes equal to
saying "this won't work".  Substitute "properly maintain all ref counts"
for X and you can see the problem.  I've seen released "production"
"tested" Python C modules with subtle refcount bugs on more than one
occasion.  In gc'd systems there are fewer places for the code to go
wrong.