[Twisted-web] Re: [Web-SIG] WSGI woes

[Alan Kennedy]

[Alan Kennedy]
 >> 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.

Regards,

Alan.