Understanding PyEval_InitThreads

[Donn Cave]

Quoth Robin Becker <robin at jessikat.fsnet.co.uk>:
| In article <7kf83526.fsf at python.net>, Thomas Heller <theller at python.net>
| writes
...
|> 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.

The callback will happen in thread A, of course (unless it doesn't,
but that's a separate question.)

In _my_ code that supports multithreaded callbacks, the callback has
access to its original thread state and uses it in PyEval_AcquireThread(),
but that isn't a requirement as far as I can see.  One (OS) thread can
set up as many new (Python) thread states as it requires on its way in
and out of the interpreter, subject to availability of the resources
involved (massive recursion might pose a problem.)  They're just a
mechanism to avoid internal concurrency.

I call PyEval_InitThreads in my modules.

	Donn Cave, donn at u.washington.edu