On Apr 13, 3:05 am, sturlamolden <[EMAIL PROTECTED]> wrote: > On Apr 11, 6:24 pm, [EMAIL PROTECTED] wrote: > > > Do I wind up with two completely independent interpreters, one per thread? > > I'm thinking this doesn't work (there are bits which aren't thread-safe and > > are only protected by the GIL), but wanted to double-check to be sure. > > You can create a new subinterpreter with a call to Py_NewInterpreter. > You get a nwe interpreter, but not an independent one. The GIL is a > global object for the process. If you have more than one interpreter > in the process, they share the same GIL. > > In tcl, each thread has its own interpreter instance and no GIL is > shared. This circumvents most of the problems with a global GIL. > > In theory, a GIL private to each (sub)interpreter would make Python > more scalable. The current GIL behaves like the BKL in earlier Linux > kernels. However, some third-party software, notably Apache'smod_python, is > claimed to depend on this behaviour.
I wouldn't use mod_python as a good guide on how to do this as it doesn't properly use PyGILState_Ensure() for main interpreter like it should. If you want an example of how to do this, have a look at code for mod_wsgi instead. If you want it to work for Python 3.0 as well as Python 2.X, make sure you look at mod_wsgi source code from subversion repository trunk as tweak had to be made to source to support Python 3.0. This is because in Python 3.0 it is no longer sufficient to hold only the GIL when using string/unicode functions, you also need a proper thread state to be active now. Do note that although multiple sub interpreters can be made to work, destroying sub interpreters within the context of a running process, ie., before the process ends, can be a cause for various problems with third party C extension modules and thus would advise that once a sub interpreter has been created, you keep it and use it for the life of the process. Graham -- http://mail.python.org/mailman/listinfo/python-list
