Breaking this out to a new thread....
Remind me again why we need async IO?
One reason is to avoid blocking while reading large content. But that
could be more simply addressed by adding an API to AsyncContext to ask the
container to read the content of the request and to do an callback (or
dispatch) once the content is read (perhaps into a file if it is really
big).
Generating large responses without blocking? Well maybe, except that async
IO does not help you with generation of large content, it only helps with
flushing of large buffers. Again rather than give direct access to IO, we
could add an API on AsyncContext that says: write this buffer and call me
back when it is all written. The container could then handle the
details.... it might even use blocking IO if it is a on a blocking
connector.
Another use-case is to process large content on the fly without blocking.
Perhaps we wanted to do this once, but now all the use cases for this are
covered by websocket I think.
Are there any other reasons for direct async IO?
regards