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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4