On Mon, 2012-04-02 at 23:23 +1000, Greg Wilkins wrote:
> > As the a) item of the algorithm indicates, the canWrite flag is flipped.
>
> So you pass a large buffer to the IO layer and it flushes it
> asynchronously and then calls back the application when it is
> finished. That is more or less the NIO.2 style, but with a needless
> copy! However it does have the ability to poll the IO layer after a
> write operation to see if a another write can be done or if a callback
> is needed - this is a good improvement (see my response to Oleksiy).
Ok, so thanks for understanding the algorithm.
> >> > Thanks for the clarification on the real purpose of what you are proposing.
> >> huh? Why do you always think I'm plotting one thing or another. I'm
> >> just trying to discuss the pros and cons of various async IO styles.
> >
> > Yes, I do think that. And I think I have reasons for that.
>
> Geeze you are seriously paranoid. No plots here. No secret plans.
> No hidden agendas. I'm not even sure what option I like best out of
> a) no async IO; b) traditional canWrite style; c) NIO.2 Style; d) Some
> new hybrid style. All I know is that we should discuss all the
> proposals and test them with real examples and analysis.
What does "no async IO" means ? Is it Servlet 3.0 with no changes ?
About ByteBuffer, a problem here is that mapped byte buffers are seen as
a general solution, where it's really not the case. Tomcat has a
specific API for files, so it has uses, but:
- it doesn't respect or use the Servlet IO (Servlet buffering, char
output)
- it's annoying with HTTP transfer encodings (chunking, compression -
although compression TE has yet to work) or won't work with content
encoding filters (compression)
Another problem is that the most optimal implementation is application
dependent. Sometimes it will be copy, sometimes not [and I chose the
copy method since it fit with the current IO structure, and I believed
it would be more often optimal]. Of course, there's a big hint if the
ByteBuffer is array based and not too large.
So probably adding a separate API with ByteBuffer (with support for
mapped ones in mind) is possible, but I wouldn't have it replace Rajiv's
proposal, I don't consider it does the same thing, it's more a
complement.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc