[Web-SIG] WSGI and greenlets

[Christopher Stawarz]

On May 7, 2008, at 4:44 AM, Manlio Perillo wrote:

> Moreover I don't see any readons to have a revc method instead of  
> read.

I just wanted to emphasize that its behavior is socket-like, not file- 
like.  It could be called read as long as its behavior is made clear  
to application developers.

>>> Unfortunately there is a *big* usability problem: the extension is  
>>> based on a well specified feature of WSGI: the gateway can suspend  
>>> the execution of the WSGI application when it yields.
>>>
>>> However if the asynchronous code is present in a "child" function,  
>>> we have something like this:
>>> ...
>>> That is, all the functions in the "chain" have to yield, and is  
>>> not very good.
>> Yes, you're right.  However, if you're willing/able to use Python  
>> 2.5, you can use the new features of generators to implement a call  
>> stack that lets you call child functions and receive return values  
>> and exceptions from them.  I've implemented this in  
>> awsgiref.callstack.  Have a look at
>>  http://pseudogreen.org/bzr/awsgiref/examples/echo_request_with_callstack.py
>> for an example of how it works.
>
> I don't think this will solve the problem.
> Moreover in your example you buffer the whole request body so that  
> you have to yield only one time.

Your example was:

def application(environ, start_response):
   def nested():
      while True:
         poll(xxx)
         yield ''
      yield result

   for r in nested():
      if not r:
          yield ''

   yield r

My suggestion would allow you to rewrite this like so:

@awsgiref.callstack.add_callstack
def application(environ, start_response):
   def nested():
      while True:
         poll(xxx)
         yield ''
      yield result

   yield nested()

The nesting can be arbitrarily deep, so nested() could yield  
doubly_nested() and so on.  While not as elegant as greenlets, I think  
this does address your concern.

> The main problem I see with greenlet is that is is not yet stable  
> (there are some problems with the garbage collector) and that is is  
> not part of CPython.
>
> This means that it can be not acceptable to write a PEP for a WSGI  
> like interface with coroutine support.

This is the problem I see with greenlets, too.  If they were part of  
the stdlib, it'd be a different story, but as things stand, I don't  
think they should be part of the spec.


Chris