David Bolen a écrit :
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

Reply via email to