Understanding PyEval_InitThreads

[Robin Becker]

In article <arj86i$1na0$1 at nntp6.u.washington.edu>, Donn Cave
<donn at u.washington.edu> writes
........
>Indeed we might be.  When Thomas Heller, Hans and I say "thread state",
>we're talking about some C data maintained by the Python interpreter -
.......
>be here */
>
>   } PyThreadState;
>
>This is not a thread, and as discussed previously, a thread is not
>constrained to only one of these.  But my point is that a thread
>should not just pick up whatever PyThreadState at random, in the
>C code that implements a callback into the interpreter.  It should
>use only a PyThreadState that belongs to it, even if it has to make
>one.  Either that, or they should all use the same one, and save
>the hassle that we currently are put to (in C callback code.)
>
>       Donn Cave, donn at u.washington.edu
I agree absolutely. I guess that the asynchronous call backs have to
choose some way to break into the python interpreter. If as you
suggested earlier you make the python part of the callback thread
agnostic then it's easy. If the callback needs to rendezvous with a
particular thread then I guess it's harder. I suppose it would need some
kind of special lock that says you can co-opt the thread do the callback
and then release the lock, it would allow exceptions a place to
propagate from. This seems so unwieldy as to be unworkable so perhaps
that's why we get the main/new thread solutions.
-- 
Robin Becker