Clearing O_NONBLOCK from a pipe may lose data

Corinna Vinschen
Mon Feb 23 12:14:00 GMT 2015

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

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


> 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Cygwin mailing list