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

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