X-Recipient:	archive-cygwin AT delorie DOT com
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=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	bh=iT6JM5XG4CiyzQxI98DMEFfNW4s=; b=pm4hjBQIOwSt+S13StgY+N4l/Fxh
	ITWBbD9yW+NMLVIjtqJ5usIRb/p1rpFNGUTbkRJtItWM7Xfj3nLtW3HWr/ynfeMB
	AQMZEqBVMS2lnbupixqYQ0AlrCLpbvZx9QAeI57wu2LprAUIUBWOiDxeyHd7sdGW
	VUi/tpF95twy0ks=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Fri, 20 Feb 2015 10:58:22 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Clearing O_NONBLOCK from a pipe may lose data
Message-ID:	<20150220095822.GP26084@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20150218220859 DOT 1e8f8b19 AT tukaani DOT org> <20150219095147 DOT GC26084 AT calimero DOT vinschen DOT de> <54E660F1 DOT 3040509 AT towo DOT net>
MIME-Version:	1.0
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--

- Raw text -