Windows NIO bug?

[Simone Bordet]

Hi,

On Fri, Jul 6, 2018 at 6:53 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> When you invoke close on a SocketChannel that is registered with one or
> more Selectors then the closing of the socket is delayed until it has
> been deregistered from all Selectors.

It was my understanding that calling close() implicitly deregistered
the socket from all selectors.
Is that not the case, so I have to manually cancel() the correspondent
SelectionKey?

> This is irrespective of the
> interest operation set. With your case A then it sounds like there is no
> selection activity

Not sure what you mean exactly, but a thread is blocked in select() on
the selector this socket is registered to.

> so this is why the close is delayed. If the client
> were reading then it would read EOF as the implementation does a half
> close.

The client does read the FIN from the server.

> There is no graceful equivalent for writing.

What I expect is a TCP RST that the server sends to the client to
inform the client that the socket is closed on the server and that
further writes are pointless, and that RST is not emitted by the
server.

On Linux it is always emitted, on Windows it is only emitted if I wake
up the selector.
Note that "wake up the selector" just means selector.wakeup(), nothing
is selected (at this point there are no keys since the only socket has
been closed), and we go back to select().
However, that seems enough to tell the Windows TCP stack to emit the RST.

That seems an inconsistent behavior, which I can certainly workaround
(by waking up the selector), but looks like a hack.
Hence asking here :)

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz