One thread freezes my whole application

[Michael Zhang]

Anders J. Munch wrote:
> "Michael Zhang" <jianqiz at bigpond.com> 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
       some_blocking_function_call();
       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?

Michael