One thread freezes my whole application

[David Bolen]

Michael Zhang <jianqiz at bigpond.com> writes:

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

One thought - if your wrapping is simple enough, you could make use of
%exception in your .i file to set up a general wrapper that would
release and then re-acquire the GIL around each of the wrapped
functions automatically.  So no need to post-process the SWIG output.

Note that this assumes your C routines aren't going to be calling into
the Python core routines, or back into Python.  In either of those
cases they'd need to re-acquire the GIL before doing so (except for a
very limited number of Python core functions that can be called
without owning the GIL).

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

No, you can't touch the GIL from the Python side.  The GIL is purely a
C-level interpreter construct.  If you have Python code executing it
already by definition owns the GIL and can't release it or else it
wouldn't be allowed to be executing :-) Any GIL management needs to be
done at C level.

-- David