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=wQtMlDx1fc3OCi+lnnAtIwpkivuNNzvLnl0dOQD1DqydSo26IinfI
	9Kjz0MEDsFg3k9tGTKLwzOGd8Z0A7ZcvFOnAu+wBWkuftYtCUXqYceF7QuPSNQGG
	UMz+NA/PpusXGC980n2P4LOEDPrWPxn7UsBF1qOaexgWivyNThEAjc=
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 11:56:53 +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: <20150223105653.GG437@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="JbKQpFqZXJ2T76Sg"
Content-Disposition: inline
In-Reply-To: <20150222220747.789401d2@tukaani.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

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.

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.

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.

The only safe way around that would be to do what Interix/SFU did, to
install a core service which all processes talk to.  Opening a file
would send the information to the server which stores it on behalf of
the file description.  fcntl calls would call the server to switch
flags, flock/lockf would do the same, the server storing all locking
information.

But that was never what Cygwin was supposed to be.  The idea was always
that you can run Cygwin processes without having to install services,
That's why we were always trying to implement as much inside the
restrictions of the DLL and not rely on an external service like
cygserver.  The only notable exception from this rule so far is XSI IPC,
which requires cygserver to run.  SOmehow it would be nice if we could
keep it that way and not go full "Windows subsytem mode"...

</rambling>

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

No, that should be doable with very minor effort.


Corinna

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

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

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

iQIcBAEBAgAGBQJU6wd1AAoJEPU2Bp2uRE+gZdYP/j5D5ElNt/68sWaq2VYKJeFm
keQWpBGaSba5ub5X+idfXhfxHbGwI96QtYNGI7AXMxMHVsvKIBM+iYNiHxPzW3KF
519Ox4EA0tZeFaUdM3NhOpYAV51Bnl6gn+Rptwm/aQAObaxyVkUt4zpBOMzliIIz
u0/JmDsFAMGbD2CtwuarQRdRmJUNBWwUFYRrsweL89oZI211ELY+S8CXUhBUchF3
kreTdmtcrGinMO3ddbo4E+H/2djTJIkBMUhVg11Bgkbn9Fe9FocAyyaSDEMa71Pr
/AUstUxiOill1PlJXQI7LWmt5JkMyIJriRUZatdoX8NF/iz9upwkSdwCbXZ3u81j
8BC90BM/DDhC9P5h74/S+7Vp0LvwgEuOvrNpKXct24QrIGTeNlzux/9b3eqZrq+D
+ZglWTD8rJEnCX8CqDwDWV5s0OvA/qb3bwrYj7NMsdNC4dTasx5f1VRclZkQcOwa
VluDv9ZYKhJtsPVgVDJpOqdQriQsUrDkkR1iDJZ4xLx7aZ+aBaY+p3LVmm2AfAQc
OS8xiybRo+JPQu5VeLofjbpYFtXg21gf/m4rcHjgOwLMsf2MCc9zP2Os+HODTvbe
LkB/Q4rM7SDvUu4WRr41D6axKDDi6fMwMG2HSc6XqJGUCNDLVnQP1SjiosZjVOPj
A9wnAYZ92VraQTYZDzLG
=eF2K
-----END PGP SIGNATURE-----

--JbKQpFqZXJ2T76Sg--