One thread freezes my whole application

[Aahz]

In article <ETV6d.9689$5O5.8558 at news-server.bigpond.net.au>,
Michael Zhang  <jianqiz at bigpond.com> wrote:
>
>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

I'm assuming you meant this:

       Py_END_ALLOW_THREADS;	# add this line as well

>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?

It's a bit more complicated than that.  The concept of the GIL applies
to both Python and C extensions; however, only C extensions can release
the GIL.

In other words, only one thread of Python code can execute at any time
because of the GIL -- try to break that and your application *WILL* blow
up.  C code that does not use *ANY* Python API may release the GIL to
allow other threads to run.  Before starting to use the Python API, the
C code *MUST* re-acquire the GIL.

Traditionally, I/O code is the prime candidate for releasing the GIL.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"A foolish consistency is the hobgoblin of little minds, adored by little
statesmen and philosophers and divines."  --Ralph Waldo Emerson