Understanding PyEval_InitThreads

[Donn Cave]

Quoth Robin Becker <robin at jessikat.fsnet.co.uk>:
| In article <1037851388.29783 at yasure>, Donn Cave <donn at drizzle.com>
| writes
| >Quoth hansgeunsmeyer at earthlink.net (hg):
|>...
|>| As far as I understand it, it doesn't really matter _what_ the thread
|>| state is that you swap into the current state before you do the
|>| callback, as long as it is _some_ valid thread state (not NULL). So,
|>| before you do the callback, at any moment when you're in the main
|>| Python thread, you could store a pointer to the then current
|>| threadstate.
|>
|> Why are there multiple thread states, then?  If we might as well just
|> use the existing state of any thread, it seems like we are put to a
|> lot of trouble to hunt one up.

| I guess we're talking cross purposes somewhat.

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 -

   typedef struct _ts {
       struct _ts *next;
       PyInterpreterState *interp;

       struct _frame *frame;
       int recursion_depth;
       int ticker;
       int tracing;
       int use_tracing;

       Py_tracefunc c_profilefunc;
       Py_tracefunc c_tracefunc;
       PyObject *c_profileobj;
       PyObject *c_traceobj;

       PyObject *curexc_type;
       PyObject *curexc_value;
       PyObject *curexc_traceback;

       PyObject *exc_type;
       PyObject *exc_value;
       PyObject *exc_traceback;

       PyObject *dict;

       /* XXX signal handlers should also 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