extension module, thread safety?

[Pierre Barbier de Reuille]

David Bolen a écrit :
> Nick Coghlan <ncoghlan at iinet.net.au> writes:
> 
> And even before that it was certainly possible to call into the Python
> interpreter from a native thread using existing functions, albeit the
> newer functions are more convenient (and perhaps more robust, I don't
> know).
> 
> My earliest interaction with Python (~1999, while writing a module
> that extended and embedded Python 1.5.2) used PyEval_AcquireThread()
> and PyEval_ReleaseThread() to get access to a thread state from a
> native C application thread (not initiated by the Python interpreter)
> to allow me to call safely into an executing Python script upon
> asynchronous data reception by the C code.
> 
> -- David

Yes, now you mention this I remember trying to use these functions ! But 
there is two problems with them (and only one is solved by the new 
functions) ! The first problem is the dead lock is you try to acquire 
the same thread twice. This implies a very low level use of these 
function, and it can be a real pain to find where to put them without 
risking this dead lock. This is no more a problem with the new 
functions. But the second (and not solved) problem is: these functions 
block the current thread when you try to get the GIL ! This is an issue 
if you don't want your GUI thread to be blocked when a buggy module does 
not release the GIL during long computations. I didn't find any function 
like "test the state of the GIL and if it's free, then acquire it" ! 
And, IMO, it's missing ... Then, if python goes to a model where 
critical sections are identified and the GIL acquired only there, all 
these problems will disappear ! That's why I really hope Python 3 will 
include this kind of thread support ...

Pierre