[Web-SIG] WSGI 2.0

[Phillip J. Eby]

At 11:08 PM 3/29/2007 -0400, James Y Knight wrote:
>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.

Right -- but the point here is that you only need to *have* an iterator if 
you're doing server push or trying to stream large files.  I don't mind 
making these corner cases a bit tougher to implement, since they're fairly 
tough already.  If you're running a WSGI 1.0 app under a 2.0->1.0 adapter, 
you can always use an adapter that ensures thread affinity.  Indeed, any 
2.0->1.0 adapter that supports multiple write() calls is going to need to 
have some sort of threading mechanism anyway, unless it uses greenlets.


>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.

I'd like to have fewer optional things, rather than more, so I think we 
should either require a dedicated thread or make it non-dedicated.  It 
should be quite straightforward to implement a middleware component that 
ensures its wrappee is run entirely within a dedicated thread, using a Queue.