[Web-SIG] Bill's comments on WSGI draft 1.4

[Robert Brewer]

Phillip J. Eby wrote:
> > I'd like to at least hear the rationale behind
> > favoring iterables so heavily over write().
> 
> One important reason: the server can suspend an iterable's execution 
> without tying up a thread.  It can therefore potentially use 
> a much smaller thread pool to handle a given number of connections,
> because the threads are only tied up while they're executing an
> iterator 'next()' call.
> 
> By contrast, 'write()' occurs *within* the application execution,
> so the only way to suspend execution is to suspend the thread (e.g. 
> waiting for a lock).

Hmm. I still don't get it--why would the server not simply "suspend
execution" of the framework within the write() call? In my naive
estimation, it would be the difference between:

for chunk in framework.data:
    output(chunk)
    do_out_of_band_stuff()

...and:

def write(chunk):
    output(chunk)
    do_out_of_band_stuff()

...and in fact, I see most existing servers having to do both when they
grow WSGI interfaces, since both are allowed in the WSGI spec (even if
one is deprecated). Maybe you could add a line or two of pseudocode to
help me understand...? (Assuming you're not fleeing for your life from
hurricanes, that is ;)

Stay safe,


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org