NIO2 AsynchronousSocketChannel: Read/Write/Timeout
Itai nsg
itainsg at outlook.com
Mon Mar 7 13:22:00 UTC 2016
Hi.
If I ask to read 10 bytes (on linux) and the first non-blocking read() syscall returns 5 bytes will the CompletionHandler get invoked specifying that 5 bytes where read or will the library be “greedy” and re-register the fd for read interest in an attempt to satisfy the entire requested byte count so long as the timeout duration has not expired? (in which case it will return a partial read of the 5 bytes and not raise a timeout error) Same goes for Windows: will it accumulate IOCP overlapped results or just return the bytes received by the first returned overlapped? Is the behavior symmetric for write?
Assuming NIO2 isn’t “greedy” would it be correct to say that a timeout occurs only if *no bytes* are read or written whatsoever by the time the timeout elapses?
The doc’s for read() state:
“Where a timeout occurs, and the implementation cannot guarantee that bytes have not been read, or will not be read from the channel into the given buffer, then further attempts to read from the channel will cause an unspecific runtime exception to be thrown.”
What exactly does: “and the implementation cannot guarantee” mean? I assume “implementation” referrers to the underlying O/S API constraints; How then can one know what the actual behavior is when the program is run under different O/S’s? What happens on Windows as opposed to Linux?
Furthermore, considering the statement: “further attempts to read from the channel will cause an unspecific runtime exception to be thrown.” Then why isn’t the channel simply “closed” by the library. I mean what can one otherwise do with channel in that state? Why isn’t ClosedChannelException thrown in case of an attempt to read from a timed-out channel?
Thanks.
Itai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20160307/b154d17a/attachment.html>
More information about the nio-discuss
mailing list