DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=h8L5HJzNtI/xb88+1EOaiI8t+1aGX3VSplO7oXavjAgHhrtBy3xsd
	erA/3sAXJRPv1YwugthKCAWK9suB/V/JjitaK22wSiTY7bXFNEd9yCE7hTD8SHVV
	m8lUKhTfjB2Uto/hQNm81acRsVZr/oZu90r74mmlCk4fSQ2JxrOkY4=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Fri, 20 Feb 2015 10:58:22 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Clearing O_NONBLOCK from a pipe may lose data
Message-ID: <20150220095822.GP26084@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20150218220859.1e8f8b19@tukaani.org> <20150219095147.GC26084@calimero.vinschen.de> <54E660F1.3040509@towo.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="7pXD3OQNRL3RjWCz"
Content-Disposition: inline
In-Reply-To: <54E660F1.3040509@towo.net>
User-Agent: Mutt/1.5.23 (2014-03-12)

--7pXD3OQNRL3RjWCz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--7pXD3OQNRL3RjWCz
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU5wU+AAoJEPU2Bp2uRE+g/zAP/2UXylfeCUVtonE003ofct1j
MApSSbVzfP6oeJrmR6q55OfWtUpvJya+bscjcXW5tJCUiJq//Iv38IqtQYCeBtRj
+3B9U7zq2O2MS0XlgRy3UQtPI/28RdaEtukFI6r5MzVG/74jw25GqIVgPtaD+txb
ystnuVrjx4HLRXQnpoUI/MCgkkBiEhtXE8lxwQAjClajsHQpOeqZroLKTuA7q9x9
JTqGHLSGSSoZZ7rBEY+x6yTro3uS89cxncFJCPpudzBK726FS8gITuUnP8EbRaC9
vue5737N80Q4aZm8b0K52keZlQ9biF1xABIU/+I1EjX/7u5xwQqZroLBZrFANQ8q
zQ6pYE7nBITHyLPXBlTDrlpR5da5hvXNznHaIAABYjShRvNjqKnr98mF4ESlQ0zk
QBdWRRY9gBfUyGQcT4gLnVFH/B0KpG13G1IltD+3i9Vp9nkTYuXl6dDHFcB601Oc
8hQHPwV85lw0tYIl3UdaaULR6QVdwZPyRDBeQROL27JRhjhRhBYLzYTfQxx40ah4
JopQnujYsVXKpXtNRcjZ+buTH3Ni/b/7ZfaLDGZ/0Nx/ZE8wwkiixoTfEW4RjiI4
Q+6BHYtu3ESRdss4J3Xt2KM9518upv3l5LnQIgaf0i9tPiy25qqwQAoc7CcGeObp
PByR8+0yk/6FSjbcTBPM
=JMhg
-----END PGP SIGNATURE-----

--7pXD3OQNRL3RjWCz--