Thread State and the Global Interpreter Lock

[Ryjek]

Peter Hansen wrote:
> Afanasiy wrote:
> 
>>On Fri, 6 Jun 2003 15:40:25 -0500, Skip Montanaro <skip at pobox.com> wrote:
>>
>>
>>>   >> Are there plans to make the Python interpreter "fully thread safe" in
>>>   >> a future version?
>>>
>>>In what way is it not "fully thread safe" today?
>>
>>http://www.python.org/doc/current/api/threads.html
> 
> 
> I suspect Skip meant to elicite from you the answer to this
> question:  What problems have *you* encountered as a result of
> the "not fully thread-safe" issue you are concerned about?

I was looking for an answer to the same question and came accross this 
thread.

Our application currently consists of two processes: one is a database 
and one is a windowing program with a user interface. Both embed a 
Python interpreter for customization purposes (i.e. you can write your 
own GUI extensions, and your own database procedures).

I would like to merge both processes into one process with two threads 
(mostly for performance purposes), but keep both threads' data separated 
the same way as they are now. Python practically does not allow me to do 
it because it insists that only one thread can execute Python bytecodes 
at a time. I would like to be able to run both interpreters in 
completely separate environments, where no state and no objects are 
shared. I believe the restriction of "one thread at a time" is too 
strict in such cases. What is the purpose of Py_NewInterpreter() if you 
cannot run it concurrently ..?

I understand that making Python completely thread safe w.respect to 
native threads may not be appropriate, but it shouldn't be that 
difficult to allow for real concurrent execution in isolated 
environments. At least, this is what they did in Perl: 
http://www.icewalkers.com/Perl/5.8.0/lib/threads.html

r