[mod_python] Problems under windows: a first diagnostic

>...
>The scoop: if python_handler() calls into Python, then returns, then
>tstate->frame should be NULL. In this scenario, you could do the
>share-tstate thing.
>
>However: somewhere down inside of python_handler's call into Python, it is
>quite possible for Python to use Py_BEGIN_ALLOW_THREADS (unlock the global
>lock). This will allow another python_handler to grab the tstate and
>attempt execution. Let's say the thread execution then flips back to
>normal: the original thread's tstate->frame is now *totally* wrong.

Wow! This looks even more complex than I thought...

>What is the solution? Each entry to python-handler should construct a
>tstate on the fly, call into Python, then destroy the tstate. I used this
>design for the Python/COM support in the Win32 distribution. That had to
>deal with reentrancy issues, but (luckily) that isn't a problem here.
>
>Presumably, you could also cache/pool tstates and yank them from your
>pool on entry to python-handler, returning them on exit. If two threads
>came into python-handler (against the same interp!), then additional
>tstates would be constructed.

I was contemplating the use of thread-local storage to maintain
the list of interpreters for which a tstate is initialized for each
Apache thread, but it's probably overkill...

Ideally, Apache should provide access to some "per-thread data area" for this,
but it does not, right?

Anyway, unless Gregory tells me otherwise, I will experiment with 
Greg's first solution and see how it works...

-Stephane