[Web-SIG] WSGI 2.0

[Ian Bicking]

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.

This aspect of SQLite totally sucks.  But I haven't encountered any 
other libraries with the same restrictions.  I might just not notice -- 
quite possible -- but still, I haven't noticed it.  And of course 
pre-fetching the results solves the problem.  The advantages seem much 
more substantial than to make it worth it to cater to one stupid library.

At least it *seems* like there's an advantage, in that an async server 
could handle lots of slow-consuming clients (or large responses) without 
a whole lot of overhead, because it could deal with all the app_iter's 
in a single thread.  If that wouldn't work anyway, then it's no good, 
but I'm assuming that could work.

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

That's essentially what wsgi.threaded and wsgi.multiprocess do.  I think 
it's a reasonable thing to give, because there is some potential that 
you'd get incorrect data instead of an exception if there really was 
problematic code.  And it would allow a SQLite user to at least call 
list() (or fetchall) on their app_iter.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
             | Write code, do good | http://topp.openplans.org/careers