> On 30 Apr 2020, at 22:20, Ivanov, Vladimir A <vladimir.a.iva...@intel.com> > wrote: > > One more update at > http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.05/ > The @apiNote section was updated a little bit to concentrate on > SO_INCOMING_NAPI_ID.
I have not seen much discussion relating to possible approaches to this new (first-time in the JDK?) read-only socket option. The current semantic, that an option returned from `supportedOptions` will not result in an UnsupportedOperationException when passed to `getOption` or `setOption`, is quite nice - this current proposal will change that. The `getOption` and `setOption` methods specify that UOE is thrown "If the socket option is not supported by this channel" - but with the current proposal this is not the case - UOE will be thrown for this new option even though the channel supports the option (`supportedOptions` contains the new option). Has any consideration been given to restricting the set of allowable integer values that may be set for this option - say, to none? Which would then lead to an IllegalArgumentException if `setOption` is invoked in an attempt to set this socket option - since no given value is allowable. --- In terms of retrieval, is `0` a valid value for this option? if so then uninitialized versus initialized states are indistinguishable. Maybe not be a problem, I dunno yet without further investigation. Also, when a non-0 value is read, is it guaranteed to remain constant thereafter, or does an application need to periodically check the socket option value. -Chris.
