[Twisted-web] Re: [Web-SIG] WSGI woes
py-web-sig at xhaus.com
Thu Sep 16 21:29:31 CEST 2004
>> In an asynchronous situation, the application cannot simply do a
>> blocking read on the input: that will tie up the server thread.
[Phillip J. Eby]
> What do you mean by "server thread"? A truly asynchronous server (one
> using "no threads") cannot serve multiple WSGI requests
> simultaneously. In the general case, a WSGI server can only serve as
> many requests simultaneously as it has available threads for.
Sorry, I should have paid more attention to phrasing in this context.
By "server thread" I mean the thread of execution that is running the
select/poll operation in the server (which needs at least *one* thread).
If the application did a blocking read of the input running in a simple,
single-threaded asyncore-style server, that single thread would block,
holding up event processing.
[Phillip J. Eby]
> [About asynchronous input handlers]
> Such a wrapper would basically be just a function returning an
> iterator, with a bunch of pausing logic and a queue to communicate
> with the actual asynchronous app. And, such wrappers should only
> need to be written once for each asynchronous API, which as a
> practical matter probably means only Twisted, anyway, as (IMO) it has
> no real competitors in the Python async framework space.
I see the need for returning an iterator: the application processing the
input has to produce a response as well: for a form-processing app
returning a "thank you for your submission" page.
But I don't see the need for pausing logic or queues? Why can't the
server simply call directly into the application, e.g. using a
"process_input" method, in effect saying "you have some input ready".
And I'm not sure I see the need for the application to check that the
wsgi.input hasn't been replaced: if there were middleware further down
that stack that was intercepting and transforming the input stream, then
*it* should be the one receiving the asynchronous notification from the
server. This lower level component would then read some input, process
it, and then call a "process_input" method on the next component up in
the stack, etc, etc.
I suppose I'm talking about the server "pushing" the input through the
middleware stack, whereas you're talking about the application at the
stop of the stack "pulling" the data up through the stack. Is that right?
And I'd be interested to see how your approach would handle a situation
where there is both streaming input and output. For example, a server
that takes strings of any length, say 10**9 bytes, and
.encode('rot13')'s each byte in turn, before sending it back to the client.
I'll be thinking about this some more.
More information about the Web-SIG