AsynchronousSocketChannel still throws unspecified exception

[cowwoc]

Alan Bateman-2 wrote:
> 
> cowwoc wrote:
>>
>>     I don't see why the <= 0 case is less clear. The way I see it, 
>> read() is an asynchronous layer on top of a synchronous readImpl() 
>> API. If we're saying that timeout <= 0 means "return immediately" then 
>> surely readImpl(timeout<=0) should return right away. read() isn't 
>> part of the equation because (as we both agree) the timeouts are 
>> really parameters for readImpl(), not read().
> It's not generally a layer over a synchronous API in blocking mode as 
> that would be problematic when there are tens of thousands of 
> connections. The timeout is also not generally something that the 
> underlying implementation knows about either. It could do in some 
> implementations but it is more likely to be an add-on with the 
> underlying implementation making use of the operating system's 
> asynchronous I/O support or maybe be based on non-blocking I/O.
> 

I feel as though we're nitpicking implementation details here. As an
end-user I picture an asynchronous read as an *abstraction* of invoking a
synchronous read in a separate thread. As an end-user I don't know or care
about the low-level details. I fully appreciate the fact that this isn't
actually the way the underlying implementation works because I've actually
implemented my own channel on top of Completion Ports, similar to the way
you have in AsynchronousSocketChannelImpl. There is no technical reason you
couldn't implement timeout <= 0 to mean "return immediately with available
bytes". I know, because I've done this for my own channel. I've provided you
with many concrete reasons why treating timeout <= 0 as "return immediately"
is the right way to go and why adding separate methods later on will cause
problems. The only reason we started with timeout <= 0 as "wait forever" was
a precedence set by C-language; but we're using Java here and
java.util.concurrent should be *our* precedence.

Is it possible to get a third person into the conversation? I think I third
pair of eyes will help us resolve this dispute.

PS: You don't need to actually *implement* timeout <= 0 as returning
available bytes. All you need to do is put it in the specification and
return 0 for now (as if there are no available bytes). We can improve the
implementation later on. I'm mostly worried about the specification here.

Gili

--
View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6580550.html
Sent from the nio-dev mailing list archive at Nabble.com.