A couple garbage collector questions

[Douglas Alan]

Neil Schemenauer <nas at python.ca> writes:

> > Why doesn't the procedure that a C extension (or embedder) uses to
> > increment the reference count of a Python object just register
> > such objects as root objects?  The reference count decrementer
> > would then unregister such objects.

> I don't know what your proposing here.  Do all objects that have a
> reference count greater than zero get registered?  Wouldn't that
> require the you keep track of all objects?

I'm not familiar with Python's "Extending and Embedding" API, so
please forgive whatever ignorance I may possess on this issue.  I
think my proposal would only involve keeping track of objects used by
extension modules.  I can see that this might be too much work in the
case of extension modules that provide new container types.  I'm
confused about these, however.  How does Python add these to the
object chain used for GC?  And how does Python find out which objects
these container types refer to?  Is it the case that for Python
objects implemented in legacy extention modules, the GC can't collect
these object or the objects they refer to?

It seems as if there wouldn't be any problem if an extension module
can just register explictly register (and unregister) certain objects
as "root" objects.  This doesn't work, however, if you want to load
unmodified legacy extension modules.  Is this, then, the real reason
for not using a typical mark and sweep?  So as to not break legacy
code?  If one were designing a new programming language for scratch
would you still be motivated to do GC the way that Python does it?

Another question: Why didn't Python just include Bohm's conservative
GC package to implement Python's cycle detection?

|>oug