On 29/04/2020 19:11, Ivanov, Vladimir A wrote:
Updated version of the webrev available as
http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/
The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels
test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched
version.
Changes:
1. comment was updated
2. names were adjusted with convention (IncomingNapiIdOptSupported =>
incomingNapiIdOptSupported, IncomingNapiIdSupported => IncomingNapiIdSupported);
Thanks for the update.
For the javadoc, I wonder if it might be simpler to drop "Incoming Napi
Id" so that the first line is "Identifies the receive queue ...". That
avoids needing to use "Napi" in the javadoc as it would need to be
defined. Your previous mail had some good text that could be massaged
into an @apiNote to give the reader some idea how this socket option
might be used. I'm in two minds on that because it is very Linux specific.
Does SO_INCOMING_NAPI_ID return a non-0 value for connections through
the loopback? Just checking as that will influence the tests that can be
created.
SO_INCOMING_NAPI_ID is supported by all socket types so I think we will
need tests to properly exercise it on the network channels defined in
java.nio.channels.
AfterClose test. The legacy Socket APIs validate parameters after they
have checked the socket state so I assume most of the changes to this
test aren't really needed. That is, I assume SocketException is thrown
always. SocketChannel and friends are different in that they validate
the parameters/input before checking the channel state.
PrintSupportedOptions. That can be simplified to use
Set.of("SO_INCOMING_NAPI_ID").
-Alan.
