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=bqs5xarpsQnS36U7QkYLlZ7r8n4CLpTPKwnkmN5rOBxZSEMQ3+lVv
	/Wo6E1h/RafvsbgR1mKiB5Os1cwaiLDM1k/u0wWsEwknU/v+hYxecCgTKzSASc0X
	wZUmehnnLpZrIf4f1AV/Ro21mmb1+vZrtVoNLxmIZHZIaZxqpn/0QI=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 23 Feb 2015 13:23:45 +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: <20150223122345.GM437@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20150222220747 DOT 789401d2 AT tukaani DOT org> <20150223105653 DOT GG437 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="bPrm2PuLP7ysUh6c"
Content-Disposition: inline
In-Reply-To: <20150223105653.GG437@calimero.vinschen.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Feb 23 11:56, Corinna Vinschen wrote:
> On Feb 22 22:07, Lasse Collin wrote:
> > Eric Blake wrote:
> > > On 02/20/2015 01:21 PM, Lasse Collin wrote:
> > > > The above Cygwin behavior would make it very easy to add a
> > > > workaround to xz for the pipe-data-loss problem: simply don't clear
> > > > O_NONBLOCK on stdout. However, I wonder if it is a bug in Cygwin
> > > > that the changes to file status flags aren't seen via other file
> > > > descriptors that refer to the same file description. If it is a
> > > > bug, then the workaround idea will cause trouble in the future when
> > > > the bug in Cygwin gets fixed.
> > >=20
> > > Yeah, the fact that cygwin is buggy with respect to POSIX may break
> > > any workaround you add if cygwin is later patched.
>=20
> The problem is two-fold.  On one hand there's Windows not supporting
> some of the POSIX concepts.  So we can't rely on the OS to keep track
> of some essential information required to emulate POSIXy behaviour.
> So that's where Cygwin needs to keep track of the inforamtion.
>=20
> On the other hand there's the way Cygwin works.  Cygwin is just a DLL.
> It can propagate settings only from parent to child process, or it can
> keep shared memory around to share information between processes of the
> same user.  Most info, as the information stored for descriptors, is
> only propagated from parent to child.  We could switch to sharing via
> shared memory, but that opens up a vector for malicious programs.
>=20
> The only safe way around that [...etc...]

It just occured to me, another way to keep info around is what Cygwin's
advisory locking does:  What we could do is to revamp parts of the code
to use per-file description objects in a subdirectory in the native NT
"BaseNamedObjects" namespace.  That's something we could follow up on
when the new account handling stuff is stable enough.

> > Alternative idea: Would there be a significant downside if Cygwin
> > remembered if non-blocking mode was enabled at some point and close()
> > would use that flag instead of the current (non)blocking status to
> > determine if the background thread hack should be used?
>=20
> No, that should be doable with very minor effort.

That's still an option, of course.


Corinna

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

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

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

iQIcBAEBAgAGBQJU6xvRAAoJEPU2Bp2uRE+gJ0EQAIcfPHZwnTTNxWdCxltWfQiX
bY1rohYJ6I+qqi2xANRR+qKrAsYAaNrBmlk8z/yW/GVks161BBFNcIYRuC1kDAWK
3phg0t73TAC3E82GIj2v8W+8ia8HDmFaI3SGOtEdNlG1ReMvLfwj7XQ8SrAozDDk
+VeZbu8aWPr+X+ehSuHiXq5/xFHK+C+NvGAi3sZo5VJ7mz992zxAKOYJ/ggGqXwn
Z9cL+/SqEjIqcMSFSnrqCGyzFM1U2XptaMQxSeo719035QiCucF/CoIiCiMvbxeM
jM2Itl2rM/x7RKCUlFFdRC0lfnGmHqt2kg3IAZliIzUJIkscuw66Sc6fuSUU5sdj
1k+SAar78Q5pp8m0AKO8fzElUhS0xDhPPehPF+EOCHUEP6xvIEllSK2pDUK/znzK
hyYIVS4iouNn26Lcvdc1/SuJTKeXfubBu3GCOmTjJYl9UG3zj8WwWXH51YKUbeB3
je00Gd9Vzh7bmdzFlRWh3mQQfOzqKYXmLQd9XIVcZ3f3EkId4WD2J/mqSbt9MXuc
5EGXhmTOJ2UwppfvzdCzvOej3NZTErRBBrA31hepgqGykoRBuXD11Au+oMzCP3Ek
I6EKMax4iBCU8ERtSCImcg8PbJWq/JCEND7m1ke0E5xqMj6NgrbmsdWYa5vS3TvY
2N8lVIeKhtrij1bsqFOP
=xelq
-----END PGP SIGNATURE-----

--bPrm2PuLP7ysUh6c--