[Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore (original) (raw)

Tim Peters tim.peters at gmail.com
Wed Dec 7 00:52:44 CET 2005

[Weber, Gregoire]

We're seriously evaluating Python for use in embedded realtime systems and need some informations about Pythons garbage collector. ...

[Neil Schemenauer]

It does not run in the background. One option would be to disable the cyclic garbage collector and rely on the reference counting alone.

Python-style refcounting isn't generally a good approach either when real-time constraints must be met: when a refcount on an object P falls to 0, not only does the interpreter "pause" to reclaim P, but also to reclaim all the objects that were reachable only from P. For example, after

def f():
    dummy = xrange(10000000)

f()

it's not just the dummy list object that's reclaimed when f exits, it's also about 10 million integer objects. Deeply nested lists and tuples (etc) can provoke similar "burps".

In that case, you will need to be sure that your code does not create reference cycles. Unfortunately I suspect there is now Python library code that requires the cyclic collector to be running.

And in the core. For example, new-style class objects are full of cycles -- although it's unlikely most programs will create a large number of new-style classes dynamically.

Are there any languages with gc that are suitable for real-time work? Probably not without a lot of effort specifically aimed at meeting real-time constraints. It's also generally true that the Python core and libraries use algorithms with good expected-case behavior but horrid worst-case behavior. For most apps, that's a big win most of the time; for real-time apps, that can be disastrous.

More information about the Python-Dev mailing list