On Jul 28, 2008, at 6:21 PM, Phillip J. Eby wrote:
At 04:57 PM 7/28/2008 -0700, Donovan Preston wrote:
On Jul 28, 2008, at 12:52 PM, Etienne Robillard wrote:
On Mon, 18 Feb 2008 04:23:38 -0800 (PST)
est <[EMAIL PROTECTED]> wrote:
I am writing a small 'comet'-like app using flup, something like
this:
<snip>
So is WSGI really synchronous? How can I handle asynchronous
outputs
with flup/WSGI ?
WSGI says that the entire body should be written by the time the wsgi
application returns.
No, it doesn't. It says that all your write() calls must be done by
then, which is not at all the same thing. If the application
returns an iterator, that iterator can keep yielding outputs until
the (figurative) cows come home.
Hmm, I see what you are saying. I hadn't thought about returning an
iterable instead of just using a generator. Cool.
So yes it is really synchronous; as Manlio
Perillo said in another message it is possible to abuse generators to
allow a wsgi application to operate in the fashion you desire, but
both the server and the application have to know how to do this and
there is no standardization yet.
This is confusing asynchronous APIs, non-blocking behavior, and
streaming output. A WSGI application can avoid blocking the server
by yielding empty strings until it is ready to produce more output.
(This may not provide any performance benefit over sleep() however,
and may in some circumstances be worse.)
You're right. But continually yielding empty strings is basically busy-
waiting, which would result in terrible performance, as you mention.
There is no async API that's part of WSGI itself, and it's unlikely
there will ever be one unless there ends up being an async API for
Python as well.
I know this has been discussed before on the list and I wasn't really
paying attention enough to know what was proposed, but it seems to me
that just having a well-defined way for the application to tell the
server when to resume the iterable is possible. Manlio has come up
with an API for this in his nginx mod_wsgi.
For example, something like the interface to select could be used:
def foo(env, start_response):
my_sock = socket.socket()
my_sock.setblocking(0)
my_sock.connect((...))
r, w, e = yield [[my_sock.fileno()], [], [my_sock.fileno()]]
if e:
...
bytes = my_sock.recv(4096)
This requires 2.5's extended generators, but the file descriptor
readiness lists could be put in the environ before resuming the
iterator for people who don't want to or can't move to 2.5.
This is just an example, I think Manlio's api (which is more like poll
if I remember correctly) is better.
Really I don't actually care, since eventlet and greenlet let me mash
together wsgi applications written with blocking i/o style with an
http server that does non-blocking i/o.
(By the way, using a generator to produce streaming output is not
abuse: it is the *intended* use of iterables in WSGI!)
Nice.
Donovan
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
