[Web-SIG] Re: Regarding the WSGI draft
Phillip J. Eby
pje at telecommunity.com
Fri Aug 27 23:36:21 CEST 2004
At 04:15 PM 8/27/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Well, if you can identify the top-level control point of PyBlosxom and
>>Roundup, you can always try converting them to WSGI. But, maybe if
>>there's a stdlib module for WSGI utilities, a useful one would probably
>>be something to run some code in such a way that it thinks it's running
>>under CGI, even though it's really running under WSGI. The degree to
>>which this could be assured is of course dependent on precisely what the
>>application *does*, but getting 80% of CGIs (that don't depend on some
>>kind of global state that isn't reset after each execution) to be able to
>>run in arbitrary WSGI servers would be a handy thing, and most
>>appropriate for the stdlib.
>I happened to be playing with just such a thing:
Wow; you certainly thought this through more than I did. E.g. your model
for dealing with threads. The part for dealing with missing
threads/threading though should probably use dummy_threading, though.
Also, I notice that you're using multiple 'environ' replacements for some
reason, even though any use of it is going to be wrapped in a global thread
lock. So, the '_environs' dictionary seems superfluous. A minimal
approach to adjusting the FieldStorage class could be:
which will make the default environ be the one you want. Doing that, and
replacing 'os.environ' for the request's duration (and putting them back
when done) seem to be required. (Note that code that doesn't use the 'cgi'
module but directly checks os.environ won't work with the current state of
Hm. Actually, I just looked and it looks like you're not wrapping the
execution in the global mutex, but you really need to because not only are
sys.std* global, CGI apps aren't generally written to be multithreaded.
Nice design otherwise, though. I particularly like that if you don't want
to run a script file, you can just override 'run_script' to do whatever the
request body is.
>There's a few parts I kind of punted on, though now that I think about it
>I know what I did wrong, so I'll fix it a bit this evening. Anyway, it's
>intended to work both for multiprocess (e.g., mod_python) and threaded
>servers, with decreasing likelihood that any particular script will
>But I haven't yet tested it under anything but CGI, so it really *should*
>work ;) I'll try running it with your WSGIServer and see how it goes.
Don't forget: WSGIServer has *not* been updated to PEP 333 yet; it's still
based on the old streaming approach! I've been too busy updating the spec
(and replying to every thread) to update the code. :)
More information about the Web-SIG