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=YmZEkmw/aWvXm6CBFflnoGfwcDQdYSDAeksJrchzHWb+qhMsEi+Ck
	9i3OpdU8hlznD/OdguUXvNf/xQhUBdct3Bc9o+2Il4PmrkvzWB39sFSnH2sNuGEY
	FsyDDn/Gz3s+Jn5KNHcaTN+if1d1HqgLbI/Ai6DNLSrsh4dCe0nSt0=
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=u90Bp+oLT14YhPw0Q7l9/okjVDw=; b=XePIGjyj5b5DYN7thu+DuJIMNtpL
	EsgnD46sLxb5Ih2gPTJEBJieEnQfm9WTDVoFh/XOWnetvS6yi8FVBOof2HY4/jQG
	SmSmOODU1PQE9FtNQX8bbuBZvLY0GX0hPDTlM+s8AtzH8M5+xTYrSTseZSmiM2ty
	hkK2sq4DUIiLE1w=
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: Mon, 23 Feb 2015 11:42:40 +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: <20150223104240.GF437@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> <145631367 DOT 20150220024700 AT yandex DOT ru> <54E6E8AF DOT 6000701 AT towo DOT net> <20150220101319 DOT GQ26084 AT calimero DOT vinschen DOT de> <54E8C3F7 DOT 8070201 AT towo DOT net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="JSkcQAAxhB1h8DcT"
Content-Disposition: inline
In-Reply-To: <54E8C3F7.8070201@towo.net>
User-Agent: Mutt/1.5.23 (2014-03-12)

--JSkcQAAxhB1h8DcT
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb 21 18:44, Thomas Wolff wrote:
> Am 20.02.2015 um 11:13 schrieb Corinna Vinschen:
> >On Feb 20 08:56, Thomas Wolff wrote:
> >>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 clo=
se
> would lead to FlushFileBuffers...

close doesn't call FFB.  It just calls a waiter thread waiting for all
async writes on pipes to be finished.  It doesn't handle a single pipe,
that's why this has to be implemented differently.

> >The question with stuff like this is usually, how long are you willing t=
o 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.

You have a point there.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--JSkcQAAxhB1h8DcT
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU6wQgAAoJEPU2Bp2uRE+gZMMP/iH3xZubMgbBYHNX5fc/hce1
yaWXah5/evfqeU//PK0jbsmUisa340bZQ8kUlE7zvNFnme4ha1PT9kg97BmMedFK
lW9aongudoEE23QF7xHfHQMesoBdFYoVeF6Ae3C2tfQK6ztMHi5JnMAyP6m4ISmw
NzGOBoJQReaIfulX+fTk4hKyhUfhMikuzAQt+dLYuQ7Soqof5eL3wYOsskn3UBEi
/JlDqvkUajYi5pB+5mVkdFt5ngISqLDFO9BAPMyIWUlhiSvizhhSEYqCV8T9xKfM
A84wOKAD8imt4eYAQO4liw7Hrwh3HUR8cUdZkjCVnACyfKLyW6UcQHbJ6onWcYNw
aYDeq98dIWsjUqcQzS6OebDZI/Wt5rb2HQnLcDMGzlD63w73T01ypJ/jQQmosz+Y
1Ty6rRSOd2q1yKstC8Gm5B6USiHF4xeX6lchGqscu8jV13S0Ye+bTlTQlZ6BU9an
tH5w3jsVkrv/9WC8A0CLwYMu+hzT+2u310fHuKwiAAymBkka1HIerMIvZZ7uqvql
1nteksVptzZQfL5DUB7F7dbLwbBmUl2eNmKWOBsZ3/7AJUY0QcfLopNSi1IvSPR5
t56yTRGz04YThdx1VqLtpP9m3Sv230SDM9dibToLrE81WDnkSjZMVFuKpq4U0nfH
KhKuYals/8qeObBw79h1
=Cacu
-----END PGP SIGNATURE-----

--JSkcQAAxhB1h8DcT--