[mod_python] Problems under windows: a first diagnostic

Gregory Trubetskoy grisha at modpython.org
Tue Jun 6 07:38:29 EST 2000

I haven't had any caffeine yet so I don't think I can comment. The Python
relationship between ThreadStates and Interpreters took me a while to
understand last time I studied it and it's one of those things that I can
only grasp for a few days until I don't need it - then, next time, I have
figure it out again.

I'll think about this some more in the coming days....

  Gregory (Grisha) Trubetskoy
       grisha at modpython.org

On Tue, 6 Jun 2000, Greg Stein wrote:

> 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/
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://www.modpython.org/mailman/listinfo/mod_python

More information about the Mod_python mailing list