Nick Coghlan <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
