One thread freezes my whole application
db3l at fitlinxx.com
Fri Oct 1 00:19:05 CEST 2004
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.
More information about the Python-list