Understanding PyEval_InitThreads

Robin Becker robin at jessikat.fsnet.co.uk
Wed Nov 20 05:54:16 EST 2002


In article <7kf83526.fsf at python.net>, Thomas Heller <theller at python.net>
writes
>Gernot Hillier <ghillie at suse.de> writes:
......
>> void call_back_into_python(PyThreadState *s)
>> {
>>     PyEval_PyEval_RestoreThread(s)
>>     // do your work
>>     PyEval_SaveThread();
>> }
>
>Unfortunately it won't work this way.
>
>Think of call_some_c_code() being the C standard library's qsort
>function, and call_back_into_python() is the function pointer I gave
>qsort to do the comparison. There's no way to pass the thread state to
>the callback function!
>
>Storing the thread state in a global variable would be possible, but
>in this case it wouldn't be thread safe, I assume, and *only* work if
>the callout into C is done by my extension module.
....
I think there's an issue here though. If the ctypes call is started in
thread A then it makes sense to ensure that thread A receives the
callback. Of course this is moot when only one python thread is running.
Perhaps this is the mainthread only issue with tkinter and the like.
-- 
Robin Becker



More information about the Python-list mailing list