On Thu, 2012-03-08 at 16:45 +1100, Greg Wilkins wrote:
> No, the servlet has to check each write to see if all the passed bytes
> were written, and if not, then give up the thread and wait for the
> canWrite callback.
It should be obvious that most small writes are going to be done
immediately, so the boolean flag stays the same as true, and the
application can continue writing (= zero cost). You should be able to
note that the container has the possibility to take care of unwritten
bytes in place of the application [my current implementation does that],
it is really up to the specification to decide this.
With a completion handler, you always have to wait for a container
callback on another thread, then signal to your thread writing output
that it can go on (this is the process that will happen with the current
proposal when the write couldn't immediately write the whole content).
For all writes, including the smallest ones.
So I can't agree with this proposal, or any where the async IO will be
blatantly inferior to blocking IO. After all, it's only one thread which
will most of the time not block, so with your scheme the application
would be better off with blocking writes.
Note: I think this was already discussed months ago when hesitating over
the style of the API, and Rajiv proposed the two main options (blocking
IO with flags, or NIO2 style). Did I miss something ?
For writing static files, this is a container task, which has a servlet
(or equivalent) in charge of sending these static files. All other
servlets have much less business dealing with static files. For reading,
I am quite reluctant about writing directly to a file, it could lead to
a lot of unwanted problems.
Note: I have a sendfile mechanism in my implementation (and it is also
in Tomcat), with a proprietary API. There has been very little demand
for access to it [OTOH, unwanted access to it caused a security issue].
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc