|
Greg Stein
gstein at lyra.org
Tue Jun 6 02:50:52 EST 2000
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/
|