This change resolves the issue where Accept() returns ERROR_NO_DATA
because the client closes the connection immediately. It resolves
the race by ignoring that particular connection and waiting on a
new one.
This exhibit a deadlock we see sometimes when using docker cli connected
to a daemon through a named pipe with some data in the input stream (ie:
`echo "hello" | docker run ... `)
The problem seems to be that the EOF 0-length message is collapsed with
the previous message, if the buffer associated with the named pipe is
not previously flushed
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
This change adds support for message mode pipes and uses them to support
CloseWrite() to better match TCP and UNIX sockets. Message mode pipes
support writing and (optionally) reading data in message-sized chunks.
This is useful for us because when in this mode a zero-sized message can
be read. We use this zero-sized message to signal that no more writes will
arrive. This is not standard practice in Windows, but it is a reasonable
compromise.
This includes Reader, Writer, and Closer interfaces on top of
Windows file handles in a way that does not block the system thread
while the IO is outstanding.
This also includes net.Listener and net.Conn for named pipes.
John Starks