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
Content-Type: text/plain; charset=windows-1252; format=flowed
X-UI-Out-Filterresults: notjunk:1;
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
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