Tim Peters wrote: > > [Guido] > > ... > > Anyway, I don't see the point: if you want two 100% independent > > interpreters, you can get that easily by forking two separate > > processes. That's what separate processes are *for*... > > So what is it that multiple interpreters within a single process *are* for? This kind of application often comes up in ASP engines where a new Python interpreter is started for each request. > I'm comfortable with threads, and comfortable with processes, but multiple > interpreters not-really-sharing yet not-really-isolated seem mostly an > opportunity to track down subtle bugs <wink>. mod_python et al. stumbled into these often enough ... it would be a Good Thing for these engines to have *all* global data of the interpreter on the heap rather than in static C globals. Extensions would have to use the same logic though, so implementing this won't be easy and will probably take a long time to get standardized. Not sure whether it's worth the pain... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
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