A SocketChannel that has registered with the Selector showing interest in both OP_READ and OP_WRITE
Actually now I understand how the windows semantics works, due to the way the underlying windows WSAAsyncSelect works....
The FD_WRITE event is handled slightly differently. An FD_WRITE message is posted when a socket is first connected with connect or WSAConnect (after FD_CONNECT, if also registered) or accepted with accept or WSAAccept, and then after a send operation fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE message and lasting until a send returns WSAEWOULDBLOCK. After such a failure the application will be notified that sends are again possible with an FD_WRITE message.
It is much easier to write non-blocking writes that way. I wish they would make the Linux and other versions work the same way.
Because in order to get the same thing I have running now on Win32 to work in Linux would be to turn my interest in the OP_WRITE event on when a write does not fully complete (bytes written < requested bytes), and off again when it is fully written.
According to the java docs using the interestOps(int) method to change that interest may block and is implementation dependent!