[PyQt] Global Interpreter Lock

[Jason Voegele]

On Friday 10 April 2009 02:35:19 pm Giovanni Bajo wrote:
> Usually, Qt applications don't require many threads because many things
> (eg: network) can be easily done without.

I'm working on a CD ripper application and using QThreads to do multiple 
encoding operations concurrently by having each encoder run in a separate 
thread.  I suppose I could use a separate process for each encoder, but I 
thought it might be easier to have the encoders report progress back to the 
GUI by using cross-thread signals, which you can't do with separate processes 
AFAIK.

> Not specifically. The presence of the GIL means that two concurrent
> threads executing Python code can't run at the same time. The fact that
> your threads have been created through QThread is immaterial. PyQt
> releases the GIL at the C++ boundary: this means that when one thread is
> executing Qt's C++ code, it's not blocking the execution of other threads.
>
> So if you call a blocking Qt operation, other threads can still continue
> their execution. If PyQt weren't handling GIL the correctly, any
> blocking Qt operation would keep the GIL locked and thus block all other
> threads at the same time.

So given that my QThread derivatives are Python code, not C++, am I to 
understand that only one of them will actually be executing at a time?  That 
doesn't seem very...concurrent. :-)

-- 
Jason Voegele
When smashing monuments, save the pedstals -- they always come in handy.
		-- Stanislaw J. Lem, "Unkempt Thoughts"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20090410/1c591bd2/attachment.bin