Re: asynchronous WSGI implementation

[email protected] ha scritto:
> On 10:32 am, [email protected] wrote:
>> Hi.
>>
>> I have started to write an asynchronous WSGI implementation for
>> Twisted Web.
>>
> [...]
>>
>> I have some questions:
>>
>> * What's the use of
>>
>>     __metaclass__ = type
>>
>>   in twisted.web.wsgi ?
> 
> This makes all classes without a base class defined in the module new-
> style.

Ok.

Then I assume it is safe to remove it, and derive every class from object.

>> * Is request.content always buffered (in memory or temporary file)?
> 
> It's always buffered, in memory if it is small, in a temporary file if
> it is large (same rules as for a normal request in Twisted Web).  

Good.
It is the same with Nginx.

> [...]

>> * In my ngx_http_wsgi_module, when the yielded string can not be sent to
>>  the client (because OS buffer is full), I suspend the execution of the
>>  application, and resume it when the socket is ready.
>>
>>  I want to do the same with Twisted, and the way to go is to be a
>>  push producer.
>>
>>  However I don't know how to implement and use the IPushProducer
>>  interface for _WSGIResponse.
> 
> The request object has a register producer method.  What else are you
> having trouble with?

I was just not sure if I just have to call registerProducer.

I have implemented it:
http://hg.mperillo.ath.cx/twisted/twsgi/rev/22738dce8721

Now the WSGI implementation is complete.

Still not sure if I should call unregisterProducer in the case
notifyFinish callback is called.
It seems that it is not required.


>>
>> By the way: it seems that the WSGI implementation in Twisted Web has
>> some bugs:
>>
>> * close method of the application iterator is not called in case of
>>  errors
> 
> This looks like a bug that should be fixed.

I will open a ticket, unless someone else already opened it.

>> * _sendResponseHeaders does not check if start_response has been called
> 
> What are the practical consequences of this?
> 

That in case WSGI application does not call start_response,
_sendResponseHeaders will fail with an AttributeError, since self.status
is not available.


Thanks  Manlio