[mod_python] Problems under windows: a first diagnostic

[Greg Stein]

On Tue, 6 Jun 2000, [iso-8859-1] Stéphane Bidoul wrote:
>...
> >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...

The cost of creating a tstate isn't all that high, in the scheme of
things. What is going to get a bit difficult is the change necessary in
get_obcallback(). It uses Py_NewInterpreter to create an interp/tstate
pair. You'll have to unwrap that into creating *just* an interpreter, thus
allowing you to create/destroy tstates at will.

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

For Apache 1.3, the only threaded platform is Windows, where TLS is going
to work out fine for you.

Apache 2.0 is a whole different story, and doesn't apply to mod_python.

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

It is a good bundle of work, but it should work quite fine. Like I said, I
used a similar pattern for embedding the Python interpreter behind the
(multi-threaded) COM interfaces.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/