On Saturday 03 January 2004 19:28, Jim Bublitz wrote: > Basically maintaining a thread state variable along with the > global interpreter lock in the interface to the interpreter. It > appears to work when the Python interpreter is loaded from a > plugin (as panel applets or control modules would do), but has > problems from a Python program: for example, if you wrote a > PyKDE program that loaded a KPart, and the KPart later tries to > load the Python interpreter (which is already running) say to > load another plugin, thread state issues arise again.
The python COM support on windows has to address the same problem. An in-process python COM server has to create the python thread state... unless it is being loaded into a python program. In that case the solution involves having the 'pythoncom' extension module track the python thread state. The COM activation machinery assumes that a pre-existing thread state exists if that extension module's init function has been called. afaik little has changed since Mark Hammond wrote this: http://mail.python.org/pipermail/thread-sig/1999-March/000305.html That all seems to work in practice, but it is brittle. It assumes that all python programs that eventually activate a python COM component will have imported pythoncom. It would be really nice to have a solution to this problem that worked across component technologies. -- Toby Dickenson _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
