09.01.2011 04:15, Alice Bevan–McGregor kirjoitti:
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO there should be simple support
for obtaining data from wsgi.input.
I'm a bit unclear as to how this will work with async. How do you
propose that an asynchronous application receives the request body?
In my example https://gist.github.com/770743 (which has been
simplified greatly by P.J. Eby in the "Future- and Generator-Based
Async Idea" thread) for dealing with wsgi.input, I have:
future = environ['wsgi.executor'].submit(environ['wsgi.input'].read,
4096)
yield future
While ugly, if you were doing this, you'd likely:
submit = environ['wsgi.executor'].submit
input_ = environ['wsgi.input']
future = yield submit(input_.read, 4096)
data = future.
That's a bit nicer to read, and simplifies things if you need to make
a number of async calls.
The idea here is that:
:: Your async server subclasses ThreadPoolExecutor.
:: The subclass overloads the submit method.
:: Your submit method detects bound methods on wsgi.input, sockets,
and files.
:: If one of the above is detected, create a mock future that defines
'fd' and 'operation' attributes or similar.
:: When yielding the mock future, your async reactor can detect 'fd'
and do the appropriate thing for your async framework. (Generally
adding the fd to the appropriate select/epoll/kqueue readers/writers
lists.)
:: When the condition is met, set_running_or_notify_cancel (when
internally reading or writing data), set_result, saving the value, and
return the future (filled with its data) back up to the application.
:: The application accepts the future instance as the return value of
yield, and calls result across it to get the data. (Obviously writes,
if allowed, won't have data, but reads will.)
I hope that clearly identifies my idea on the subject. Since async
servers will /already/ be implementing their own executors, I don't
see this as too crazy.
-1 on this. Those executors are meant for executing code in a thread
pool. Mandating a magical socket operation filter here would
considerably complicate server implementation.
- Alice.
_______________________________________________
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/alex.gronholm%40nextday.fi
_______________________________________________
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
