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=pCva0U+oGojBuJj1fceiHrJ8IsDVhvckVQdCaSztpLm
	t7ORNRia+Rnl/xa3p7KVdnvGpfSEzfu8Tqj/VK+5XaomqRAea+zyojxyOT0tHkFX
	tKmAtCSsyZHV6ZbG4BKY+hrlZ+DyWBUp3Rw5HHHquZmbg7hUZ5LeTwGrPQmb5rBo
	=
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=QY0AUjt/nFQJdmQFSEZEC6EpScA=; b=Lg9IjvxdNWKNBsunS
	4b3KuLldyANd62b2V1WnzovNpmtdEJbvxHrWqorcLzfrRqCFjxMFvkOBMgJ3cH1L
	VXIyBmvLJ0VWJhlNDiHPYrLpEDTjzUYwSqpRDJL79LbfQSgzsdtKnQS9nbxv8UYV
	mBz3GUdBdNNrbKGYJPZ26J1YfE=
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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO: mout.kundenserver.de
Message-ID: <54E8C3F7.8070201@towo.net>
Date: Sat, 21 Feb 2015 18:44:23 +0100
From: Thomas Wolff <towo AT towo DOT net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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> <54E6E8AF DOT 6000701 AT towo DOT net> <20150220101319 DOT GQ26084 AT calimero DOT vinschen DOT de>
In-Reply-To: <20150220101319.GQ26084@calimero.vinschen.de>
X-TagToolbar-Keys: D20150221184422933
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-UI-Out-Filterresults: notjunk:1;
X-IsSubscribed: yes

Am 20.02.2015 um 11:13 schrieb Corinna Vinschen:
> On Feb 20 08:56, Thomas Wolff wrote:
>> 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.
> You mean the actual act of changing the descriptor from non-blocking
> to blocking, as in fcntl(fd, F_SETFL), shall perform the same action
> of waiting as the close call on non-blocking descriptors does?
Yes.
>> 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.
> I'm not sure that works as desired, but it's probably worth a try.  An
> fcntl method for pipes has to be added (there is none yet, it's all done
> in fhandler_base::fcntl), then the F_SETFL command would have to be
> augmented to create a thread calling FlushFileBuffers (which is
> *supposed* to work on pipe handles but I never tried it myself), and the
> fcntl call would have to wait for thread completion, allowing
> interruption by signals (calling cygwait, that is).
where the actual code (as I understood you) could be copied from close() 
code. Although I looked into the code and didn't find the place where 
close would lead to FlushFileBuffers...
> The question with stuff like this is usually, how long are you willing to wait?
Indefinitely...
>    You never know what the reader side of a pipe is doing.  It
> might just be busy and intends to read from the pipe in a second, a
> minute, or an hour.
... like it is normal when feeding a pipe in blocking mode (which we 
just switched to). I don't see a problem here.
------
Thomas

--
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