[Twisted-web] Draft language for WSGI to forbid blocking by middleware

Phillip J. Eby pje at telecommunity.com
Thu Sep 16 12:03:27 MDT 2004

I'm proposing the following language to be added to PEP 333, as a 
subsection under "Buffering and Streaming", just before the subsection 
entitled, "The write() callable".  It doesn't address pausing or resuming 
iteration (which I don't have a PEP-able proposal for yet), but it should 
ensure that middleware doesn't introduce any additional blocking issues:

===excerpt start===

Middleware Handling of Block Boundaries

In order to better support asynchronous applications and servers,
middleware components **must not** block iteration waiting for
multiple values from an application iterable.  If the middleware
needs to accumulate more data from the application before it can
produce any output, it **must** yield an empty string.

To put this requirement another way, a middleware component **must
yield at least one value** each time its underlying application
yields a value.  If the middleware cannot yield any other value,
it must yield an empty string.

This requirement ensures that asynchronous applications and servers
can conspire to reduce the number of threads that are required
to run a given number of application instances simultaneously.

Note also that this requirement means that middleware **must**
return an iterable as soon as its underlying application returns
an iterable.  It is also forbidden for middleware to use the
``write()`` callable to transmit data that is yielded by an
underlying application.  Middleware may only use their parent
server's ``write()`` callable to transmit data that the
underlying application sent using a middleware-provided ``write()``

===excerpt end===

In addition to this insertion, I would modify the 'start_response()' 
specification to note that HTTP headers should not be sent until the first 
*non-empty* string is yielded from the iterable.


More information about the Twisted-web mailing list