On 7 Sep, 13:17, Ulrich Eckhardt <eckha...@satorlaser.com> wrote: > Quoting from above: "The GIL is global to the process". So no, it is NOT > private to each thread which means "python" isn't either. > > At least that is my understanding of the issue.
Strictly speaking, the GIL is global to the Python DLL, not the process. You can load it multiple times from different paths, and if you do GIL with not be shared. If you make several clean installs of Python on Windows (say c: \Python26-0 ... c:\Python26-3), you can embed multiple interpreters in a process, and they will not share GIL or anything else. But be careful: all *.pyd files must reside in these directories, or they will be loaded once and refcounts screw up. The Python DLL must also be in these directories, not in c:\windows\system32. It is in fact possible to make Python utilize dual- and quad-core processors on Windows this way. You can even use ctypes for embedding Python into Python, so no C is required. See: http://groups.google.no/group/comp.lang.python/browse_thread/thread/2d537ad8df9dab67/812013f9ef3a766d To make this hack really work one need multiple complete installs, not just copies of one DLL as I assumed in the thread. But the general method is the same. You can see this as a form of primitive object orientation :P Sturla Molden -- http://mail.python.org/mailman/listinfo/python-list
