This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Clearing O_NONBLOCK from a pipe may lose data

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.
> > > 
> > > 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 [...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?
> No, that should be doable with very minor effort.

That's still an option, of course.


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

Attachment: pgpR15K9L4p6w.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]