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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=B1/sdXr7SpRA8FivISXSQITWw/cTFrOZkMJUIasQDRZ
	LZUnH9309xTuXcKOhPtCovtybqhxWd5KBF4jSJuruliPPfgz2iaBeMd3V1q3xWtH
	vNDfsTVaV71LFl+3I00JaALH6lGBHo01Fxq/UnCaqmRNAZJpCAPYJgbbGvQcAfAs
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=E64bY87YQUh+PV84SDWYo0Tjckw=; b=uxSc68GVnyZ0B9Xk5
	+WAj03LJbPHIlTBPQHw1X3jG2TRxqgVEnhosHFsoFCUYLvL+2bISDJTTu1A5G0ky
	4tvUVE3na3AWfgvpz1u79tyNwIIM4jS1IFQBRbccgcMSpYStZCwULutARQX7GThD
	m+s4IAMT6vPa5Ma3zpxtT8dg/w=
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=2.2 required=5.0 tests=AWL,BAYES_40,FOREIGN_BODY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2
X-HELO:	mout.kundenserver.de
Message-ID:	<54E6E8AF.6000701@towo.net>
Date:	Fri, 20 Feb 2015 08:56:31 +0100
From:	Thomas Wolff <towo AT towo DOT net>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Clearing O_NONBLOCK from a pipe may lose data
References:	<20150218220859 DOT 1e8f8b19 AT tukaani DOT org> <20150219095147 DOT GC26084 AT calimero DOT vinschen DOT de> <54E660F1 DOT 3040509 AT towo DOT net> <145631367 DOT 20150220024700 AT yandex DOT ru>
In-Reply-To:	<145631367.20150220024700@yandex.ru>
X-TagToolbar-Keys:	D20150220085631385
X-UI-Out-Filterresults:	notjunk:1;
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id t1K7uuHV005129

Am 20.02.2015 um 00:47 schrieb Andrey Repin:
> Greetings, Thomas Wolff!
>
>> 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?
> You can't "just flush" it, if the receiving end isn't reading from it.
By flushing I meant actually waiting until it's been consumed at the
other end in this case, if that's technically feasible.
I see no strict requirement that the fcntl call removing O_NONBLOCK from
a file descriptor should itself still be handled as nonblocking (it can
well be argued that the flag is changed first and then the call is
allowed to block) - and even if this were not proper it is certainly
more acceptable than losing data.
------
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -