[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.
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