One thread freezes my whole application

Michael Zhang jianqiz at
Thu Sep 30 17:46:44 CEST 2004

Anders J. Munch wrote:
> "Michael Zhang" <jianqiz at> wrote:
>>The problem is when I click the connection button and invoke that
>>connection thread, the whole application (including base thread and
>>display thread) was frozen. What I expected was when one thread is
>>listerning the socket, the display thread should be able to continue its
>>running, and I should be able to invoke other (if any) threads from the
>>GUI base thread. Afterwards, I had to use ps/kill to clean them up.
> [...]
>>     def run(self):
>>Cmodule.create_connection() # Cmodule is created from C
> Do I understand you correctly that Cmodule is a C extension?
> If create_connection includes C code that does blocking I/O without
> releasing the global interpreter lock, your whole application will
> block.  Perhaps that's what you're seeing.

Thank you, Anders

Your hint on GIL leads me quite lots of searching and reading on Google. 
After several hours confusion (due to those different opinions), I 
finally come to a quite simple and amazing solution:

       Py_BEGIN_ALLOW_THREADS;	# add this line
       Py_BEGIN_ALLOW_THREADS;	# add this line as well

Now I've got what I really expected.

However, there is a new question (rather than a problem). Since my 
Cmodule is created using SWIG, if there is any change in the original C 
code, I have to run swig again to get new "Cmodule_wrap.c" file, and add 
above two lines into that new wrapper file, then build a new module. 
It's quite uncomfortable during debugging. Is there any way I can use to 
achieve the same goal on Python side code, rather that on C extension 
side? Can I just modify the Python code to release that GIL? or Do I 
have any misunderstading about GIL, say, the concept about GIL only 
applies to C extension rather than Python threading itself?


More information about the Python-list mailing list