On 2011-01-08 20:06:19 -0800, Alex Grönholm said:
I liked the idea of having a separate async_read() method in
wsgi.input, which would set the underlying socket in nonblocking mode
and return a future. The event loop would watch the socket and read
data into a buffer and trigger the callback when the given amount of
data has been read. Conversely, .read() would set the socket in
blocking mode. What kinds of problems would this cause?
Manipulating the underlying socket is potentially dangerous
(pipelining) and, in fact, not possible AFIK while being
PEP444-compliant. When the request body is fully consumed, additional
attempts to read _must_ return empty strings. Thus raw sockets are
right out at a high level; internal to the reactor this may be
possible, however. It'd be interesting to adapt marrow.io to using
futures in this way as an experiment.
OTOH, if you utilize callbacks extensively (as m.s.http does) you run
into the problem of data passing. Your application is called (wrapped
in middleware), sets up some futures and callbacks, then returns. No
returned data. Middleware just got shot in the foot. The server,
also, got shot in the foot. How can it get a resopnse tuple back from
a callback? How can middleware be utilized? That's a weird problem to
wrap my head around. Blocking the application pending the results of
various socket operations is something that would have to be mandated
to avoid this issue. :/
Multiple in-flight reads would also be problematic; you may end up with
buffer interleaving issues. (e.g. job A reads 128 bytes at a time and
has been requested to return 4KB, job B does the same... what happens
to the data?) Then you begin to involve locking...
Notice that my write_body method [1], writes using async, passing the
iterable to the callback which is itself. This is after-the-fact
(after the request has been returned) and is A-OK, though would need to
be updated heavily to support the ideas of async floating around right
now. I'm also extremely careful to never have multiple async callbacks
pending (and thus never have muliple "jobs" for a single connection
working at once).
- Alice.
[1]
https://github.com/pulp/marrow.server.http/blob/draft/marrow/server/http/protocol.py#L313-332
_______________________________________________
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
