adding rsockets support into JDK

[Alan Bateman]

On 18/12/2018 19:44, Lu, Yingqi wrote:
> Hi Alan/Chris,
>
> Here is the version 26 of the patch: http://cr.openjdk.java.net/~ylu/8195160.26/
>
> :
>
> Then, following Alan's suggestion, I made the rsocket to be non-blocking at the creation time for socket channels. I modified accept function from RdmaServerSocketChannelImpl, and connect/read/write functions from RdmaSocketChannelImpl to simulate blocking. Please let me know if this is a reasonable approach. I tested the patch with all 23 JTreg test cases and they all pass (I commented out all 12 tests for non-blocking connect cases in IOExchanges.java given issue #2 is still open)
>
I've been busy in other areas so just skimmed 8195160.26 to get a feel 
for this version.

Is the current proposal to just emulate blocking I/O for the connect and 
accept operations (as you said in your mail) and let the RDMA lib 
emulate it for the read/write operations? I guess I assumed from the 
December mails that it would be all operations to keep the 
implementation simple.

I'm mostly asking because I assumed implConfigureBlocking would be close 
to a no-op, or more specifically it should just acquire the locks, call 
ensureOpen and nothing else. It still calls RmdaNet.configureBlocking in 
this version so it can toggle the blocking mode before a connect is 
attempted.

Also, the read/write methods now have checkNonBlockingIO to poll the 
rsocket when there is spurious wakeup so they can already providing 
blocking semantics when the channel is configured blocking. In passing, 
it might be more readable to use RdmaNet.poll so that it's clear that 
they are polling the socket for readiness. The methods used by the 
socket adpater already does this which makes that code a bit easier to 
read. Also if emulation is extended to read/write then the check for 
IOStatus.INTERRUPTED can be eliminated from the outer loop.

Chris has an environment to test out the patches so I assume he will 
have comments too. At this point I'm just trying to understand whether 
the approach is to emulate blocking I/O everywhere or just the two 
operations.

-Alan