8198562: (ch) Separate blocking and non-blocking code paths (part 1)

[Alan Bateman]

David Holmes pointed out off-list that the change to Thread.interrupt 
creates a potential issue when the nterrupt status is cleared just 
before a blocking I/O operations is start, e.g.

try { Thread.sleep(duration); } catch (InterruptedException e) { }
channel.read(..)

If something interrupts the sleep then it will race with the above as it 
clears the interrupt status and sets the blocker for the I/O operation. 
This may mean the blocking I/O operation completes with 
ClosedByInterruptedException and without the interrupt status being set.

To fix this then we need to go back to setting the interrupt status 
whilst holding the blockerLock. This means it works the same as JDK 
1.4-10 except that it handles the case where attempts its own interrupt 
status whilst in a blocking I/O (a source of potential deadlocks as we 
know from other discussions here).

http://cr.openjdk.java.net/~alanb/8198841/webrev/index.html

-Alan