extension module, thread safety?

[Pierre Barbier de Reuille]

David Bolen a écrit :
> 
> If the threads under discussion are all Python threads, then by
> default yes, the extension module C functions will appear to be atomic
> from the perspective of the Python code.  When the Python code calls
> into the extension module, the GIL (global interpreter lock) is still
> being held.  Unless the extension module code explicitly releases the
> GIL, no other Python threads can execute (even though those threads
> are in fact implemented as native platform threads).

Indeed, there is this (so annoying) GIL ... is there any project about 
extracting the (few ?) critical points of the python interpreter to put 
locks around them instead of choosing the opposite strategy (ie. locking 
anythime but when we know the section is not critical) ? Because it 
would made embedding a python interpreter in another language much more 
easy !

With the current CPython, it's very hard to mix Python and C in a 
multithreading application (with C-threads, not Python-threads). In fact 
I never really succeeded in that task because of that GIL ! I have a 
multi-thread application but every bit of Python code must be run into a 
Python thread. To be more precise, I wanted to be able to call Python 
code in response to some GUI events, and I didn't want to instanciate a 
new interpreter for I wanted to be able to access the environment of my 
main Python interpreter.

By the way, if someone succeeded in a similar task, I'll be happy to 
hear about it :)

Pierre

PS: if the main code is in C (in fact C++ ...) and not Python it's for 
historical reasons of course ;)