[Web-SIG] WSGI 2.0
Ian Bicking
ianb at colorstudy.com
Fri Mar 30 06:11:33 CEST 2007
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
More information about the Web-SIG
mailing list