Multiple interpreters retaining huge amounts of memory

"Martin v. Löwis" martin at
Sun Feb 3 08:38:18 CET 2008

> If you are going to make a comment such as 'multi-interpreter feature
> doesn't really work' you really should substantiate it by pointing to
> where it is documented what the problems are or enumerate yourself
> exactly what the issues are. There is already enough FUD being spread
> around about the ability to run multiple sub interpreters in an
> embedded Python application, so adding more doesn't help.

I don't think the limitations have been documented in a systematic
manner. Some of the problems I know of are:
- objects can easily get shared across interpreters, and often are.
   This is particularly true for static variables that extensions keep,
   and for static type objects.
- Py_EndInterpreter doesn't guarantee that all objects are released,
   and may leak. This is the problem that the OP seems to have.
   All it does is to clear modules, sys, builtins, and a few other
   things; it is then up to reference counting and the cycle GC
   whether this releases all memory or not.
- the mechanism of PEP 311 doesn't work for multiple interpreters.

> Oh, it would also be nice to know exactly what embedded systems you
> have developed which make use of multiple sub interpreters so we can
> gauge with what standing you have to make such a comment.

I have never used that feature myself. However, I wrote PEP 3121
to overcome some of its limitations.


More information about the Python-list mailing list