Threading, real or simulated?

[Antoon Pardon]

Op 2005-09-22, Sam schreef <sam at email-scan.com>:
> Jp Calderone writes:
>
>> On Wed, 21 Sep 2005 18:23:33 -0500, Sam <sam at email-scan.com> wrote:
>>>I'm using Python 2.3.5 with pygtk 2.4.1, and I'm using the second threading 
>>>approach from pygtk's FAQ 20.6 - invoking "gtk.gdk.threads_init()", and 
>>>wrapping all gtk/gdk function calls with 
>>>gtk.threads_enter()/gtk.threads_leave()
>>>
>>>I start a thread, via thread.Threading.start().  The thread then calls a 
>>>particularly time consuming C function, from an extension module.  I find 
>>>that when the thread is running the C code, the GUI hangs even though I'm 
>>>not inside the threads_enter/threads_leave territory.
>>>
>> 
>>   Does the extension module release the GIL?  It sounds like it does not. 
>>   Of course, there are a dozen other mistakes that could be made which would
>>   have roughly this symptom.  It's difficult to say which is the problem
>>   without actually seeing any code.
>
> What's the GIL?.

The general interpretor lock. In general changing python internals
is not thread-safe. The current implementation uses a lock (the GIL)
for thread to safely rebind variable or mutate object. The result
is that threads are serialised.

> The extension module is invoked outside of 
> threads_enter/threads_leave().
>
>>>It looks like thread.Threading() only simulates threading, by having the 
>>>python interpreter multiplex between running threads.  Is real threading 
>>>possible, so that I do something time-consuming in the thread, without 
>>>hanging the GUI?
>>>
>> 
>> Assuming you mean threading.Thread, this is a native thread.  It is not a simulation.  Something else is going wrong.
>
> Then I must have something locked.  Here's what I do:

Yes you have locked the GIL. Take a look at the following
URL: http://docs.python.org/api/threads.html, hope it helps.

-- 
Antoon Pardon