[PyQt] Global Interpreter Lock
Jason Voegele
jason at jvoegele.com
Fri Apr 10 20:35:01 BST 2009
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
More information about the PyQt
mailing list