On Mon, 2012-03-12 at 09:52 +1100, Greg Wilkins wrote:
> On 9 March 2012 19:14, Remy Maucherat <rmaucher_at_redhat.com> wrote:
> > Your proposal is functionally complete more or less so it does not look
> > unacceptable to me, although I strongly prefer the one from Rajiv. I
> > thought, from the feedback that was posted until now, that everyone was
> > fine with Rajiv's drafts, but apparently it is not the case anymore. So
> > let's see more feedback.
>
> Glad I finally explained myself well enough.
>
> Having put that out there, for me as a developer, I probably actually
> agree with you. I'm very used to async IO that does read/write
> available call backs and I believe it is probably the more flexible of
> the two approached. I'm just very concerned that it is a lot harder
> to use and that I might not be the typical developer that this is
> intended for. NIO had this style of async and have moved away from it
> to the NIO.2 style, and the JDK developers will have had far more
> exposure to the average IO developer than we have.
The complexity of the two is actually equivalent, no need to mislead
people with a dubious NIO 1 comparison. In both cases you have to wait
for a callback on another thread, and do the same thing in both (sync
with the main thread to tell it to go on, presumably). The completion
handler makes this mandatory on every write (or read), so it would
degrade performance. This is why I favor the efficient solution.
> I understand the desire to use readers/writers for async IO, but I do
> not believe that any code that is written now against the
> reader/writer APIs can be safely used against async versions of those.
> This is because that code is written assuming blocking semantics.
> For example, you will often see Readers wrapped as BufferedReaders, so
> that the readLine() API can be used. This would fail horribly if the
> underlying reader was async. It may be a feature not a bug that
> async IO mechanism cannot be fed to existing IO code.
Rajiv has already clarified that, unless read/write listeners are set,
the API remains blocking, thus offering full compatibility. If they wrap
with some buffered reader and insist on using the listeners to get
async, the user will get his well deserved ISE (note: in my own
implementation, it will automagically block, so it really depends on
what the spec chooses to say - I think the spec is right, my behavior
has too much magic).
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc