Clearing O_NONBLOCK from a pipe may lose data

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Feb 20 11:48:00 GMT 2015


On Feb 19 23:17, Thomas Wolff wrote:
> Am 19.02.2015 um 10:51 schrieb Corinna Vinschen:
> >On Feb 18 22:08, Lasse Collin wrote:
> >>(Please Cc me when replying, I'm not subscribed to the list.)
> >>
> >>Hi!
> >>
> >>I suspect that there is a bug in Cygwin:
> >>
> >>1. Create a pipe with both ends in blocking mode (O_NONBLOCK
> >>    is not set).
> >>2. The writer sets its end to non-blocking mode.
> >>3. The writer writes to the pipe.
> >>4. The writer restores its end of the pipe to blocking mode
> >>    before the reader has read anything from the pipe.
> >>5. The writer closes its end of the pipe.
> >>6. The reader reads from the pipe in blocking mode. The last
> >>    bytes written by the writer never appear at the reader,
> >>    thus data is silently lost.
> >>
> >>Omitting the step 4 above makes the problem go away.
> >I can imagine.  A few years back, when changing the pipe code to
> >using overlapped IO, we stumbled over a problem in Windows.  When
> >closing an overlapped pipe while I/O is still ongoing, Windows
> >simply destroys the pipe buffers without flushing the data to the
> >reader.  This is not much of a problem for blocking IO, but it
> >obviously is for non-blocking.
> >
> >The workaround for this behaviour is this:  If the pipe is closed, and
> >this is the writing side of a nonblocking pipe, a background thread gets
> >started which keeps the overlapped structure open and continues to wait
> >for IO completion (i.e. the data has been sent to the reader).
> >
> >However, if you switch back to blocking before closing the pipe, the
> >aforementioned mechanism does not kick in.
> Could not "switching back to blocking" simply be handled like closing as far
> as the waiting is concerned,
> thus effectively flushing the pipe buffer?

Flushing the pipe buffer (using FlushFileBuffers) can block the process
indefinitely if the reader doesn't read for some reason.  This is a
problem in the Windows implementation of pipes.  For some reason there
doesn't seem to be a kernel buffer which can be used to decouple writer
and reader a bit.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150220/3d59b0e6/attachment.sig>


More information about the Cygwin mailing list