[Web-SIG] WSGI 2.0

[James Y Knight]

On Mar 29, 2007, at 10:41 PM, Phillip J. Eby wrote:

>> It's not clear if the app_iter must be used in the same thread as the
>> application.  Since the application is blocking, presumably *it*  
>> must be
>> run all in one thread.  This should be more explicitly documented.
>
> Definitely.  I think that we should not require thread affinity  
> between the
> application and the app_iter -- my feeling at this point is that  
> actual
> yielding is an edge case with respect to most WSGI apps.  The  
> common case
> WSGI application should be just returning a list or tuple with a  
> single
> string in it, and not doing any complex iteration.  Allowing the  
> server
> more flexibility here is probably the better choice.
>
> Indeed, I'm not sure we should require thread affinity across  
> invocations
> of app_iter.next().

I recall last time this issue was considered, one of the fundamental  
problems is that, if the same thread isn't used for both the app and  
all app_iter.next invocations, sqlite cannot be used. (unless you  
don't call sqlite functions in the iterate part, of course). And I'm  
sure there's other libraries that are similarly thread-safe but only  
if you restrict yourself to a single thread per handle.

That problem made me uncomfortable enough with using non-dedicated  
threads that I didn't attempt it. If WSGI 2.0 explicitly states that  
each call to the app's iterator can occur on a different thread, then  
I'd be more confident in telling people that it's their code that was  
broken. I suppose another flag could be added "wsgi.dedicated_thread"  
which is True only if every call to .next will be on the same thread  
as the call to your app. Of course that doesn't really help an app  
broken by it, just lets them error out early.

James