Catching up on this thread -
On 3/6/2012 1:44 PM, Greg Wilkins wrote:
>
> 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).
I don't think we should tie Async IO necessarily with Async request
processing that was introduced in 3.0. While it should be possible to
use it from the AsyncContext but should not require the async request
processing.
>
> 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?
Performance and throughput in the web container. I think we need to make
sure that we don't consume too many container resources in I/O similar
to what we did with the async processing in 3.0.
- Rajiv
>
>
> regards
>