Instead of "appdomains" (one interpreter per thread), or free threading, you could use multiple processes. Take a look at the new multiprocessing module in Python 2.6. It has roughly the same interface as Python's threading and queue modules, but uses processes instead of threads. Processes are scheduled independently by the operating system. The objects in the multiprocessing module also tend to have much better performance than their threading and queue counterparts. If you have a problem with threads due to the GIL, the multiprocessing module with most likely take care of it.
There is a fundamental problem with using homebrew loading of multiple (but renamed) copies of PythonXX.dll that is easily overlooked. That is, extension modules (.pyd) are DLLs as well. Even if required by two interpreters, they will only be loaded into the process image once. Thus you have to rename all of them as well, or you will get havoc with refcounts. Not to speak of what will happen if a Windows HANDLE is closed by one interpreter while still needed by another. It is almost guaranteed to bite you, sooner or later. There are other options as well: - Use IronPython. It does not have a GIL. - Use Jython. It does not have a GIL. - Use pywin32 to create isolated outproc COM servers in Python. (I'm not sure what the effect of inproc servers would be.) - Use os.fork() if your platform supports it (Linux, Unix, Apple, Cygwin, Windows Vista SUA). This is the standard posix way of doing multiprocessing. It is almost unbeatable if you have a fast copy-on- write implementation of fork (that is, all platforms except Cygwin). -- http://mail.python.org/mailman/listinfo/python-list
