8222774: (ch) Replace uses of stateLock and blockingLock with explicit locks

[Alan Bateman]

On 23/04/2019 15:34, Daniel Fuchs wrote:
> :
>
> I was wondering about the asymmetry. It looks like
> the former if (blocking) { while() { ... } } might be more
> correct, as it ensure that isOpen() is also checked between
> the first and second call to the IO primitive which is
> being wrapped? (same goes for ServerSocketChannelImpl.java
> SocketChannelImpl.java, SinkChannelImpl.java)
DatagramChannel.receive is a bit different as the non-blocking case may 
return null instead of a sender address.  However, point taken that we 
could change this to do-while so at least the blocking case is closer to 
the idiom used in the other locations.

>
> DatagramSocketAdaptor.java:
>
>  279     @Override
>  280     public int getSoTimeout() throws SocketException {
>  281         if (!dc.isOpen())
>  282             throw new SocketException("Socket is closed");
>
> Is there any backward compatibility concern with this
> change? 
DatagramSocket.setSoTimeout has always thrown IAE for this case. Chris 
has picked up JDK-8222829 to align the spec with the long standing 
behavior. We had the same issue very recently with 
ServerSocket.setSoTimeout.


>
> AdaptorStreams.java:
>
> Has this test run through tier8? This is where the special
> VM configurations happen - and it's been known to trigger
> intermittent failure more often than the other tiers.
>
> I see the test use 1000 and 2000 millis, reasoning that if
> the timeout is 2000ms then something scheduled to happen
> after 1000ms should not trigger the timeout - and I wonder
> how stable that is going to be.
Daniel and I went through each of the tests using a timeout and I think 
we've satisfied ourselves that the timeouts are long enough so that 
there shouldn't be an issue on really slow test machines/

-Alan.