delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |