Understanding PyEval_InitThreads

[Donn Cave]

Quoth Thomas Heller <theller at python.net>:
| "Donn Cave" <donn at drizzle.com> writes:
...
|> 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.
|
| The thread state is, well, the state of a thread. So at least they
| cannot be shared across threads.

Right.

| I had multiple other schemes saving thread states when calling out to
| C from Python, and getting thread states when calling back into Python
| from C, including stacks of thread states in thread local storage.
| Some of them worked, some were fragile.

I'm fortunate to have an object associated with each thread in the API
I'm working with (BeOS), and all the API callback functions are naturally
endowed with the ability to find that object, so that's where my thread
state is.  If it were otherwise, I might have been tempted to develop a
thread:state database.

| Second, profiling and setting breakpoints won't work across callouts
| and callins because the profiling and tracing is done with objects
| stored in the thread state itself, and creating a new one doesn't
| inherit them from the saved state. This also affects exceptions, which
| are not propagated back into the 'callout' from the 'callin'.
|
| Hm, can anyone understand the last sentence?
| What I mean is: When an exception occurs in the callback (which runs
| with a newly created thread state), simply PyErr_Print() is called
| before the thread state is deleted, because there's no way to pass
| the exception somewhere else.

I can understand it - but alas, have no idea for a solution.

	Donn Cave, donn at u.washington.edu