[PyKDE] KControl Modules II (Simon Edwards)

[Toby Dickenson]

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