One thread freezes my whole application
aahz at pythoncraft.com
Thu Sep 30 19:28:08 CEST 2004
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
> 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
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
More information about the Python-list