In the ServerSocketChannelImpl.java, it holds the blockingLock, and because it is in blocking mode, so the accept() keep waiting. But in another thread which want to change the blocking mode, it also want to hold the blockingLock in the configureBlocking(boolean) method, which result in a deadLock.
In the patch, I simply remove the sychronized block to resolve the thread deadlock because the bolckingLock has been synchronized in blockingLock() method located in AbstractSelectableChannel.
This patch can make the test pass and no new test failures found in luni and nio unit tests.
I wonder, does this change hava any side effect?
If the main thread got the blocking mode and release the blockingLock, then before the main thread do the real IO operations, another thread change the blocking mode, what behavior it should be?
I found following description in the spec of the InterruptibleChannel interface says:
"A channel that implements this interface is asynchronously closeable: If a thread is blocked in an I/O operation on an interruptible channel then another thread may invoke the channel's close method. This will cause the blocked thread to receive an AsynchronousCloseException."