Clearing O_NONBLOCK from a pipe may lose data

Lasse Collin
Tue Feb 24 15:25:00 GMT 2015

On 2015-02-24 Corinna Vinschen wrote:
> On Feb 24 08:16, Thomas Wolff wrote:
> > Am 23.02.2015 um 13:23 schrieb Corinna Vinschen:
> > >On Feb 23 11:56, Corinna Vinschen wrote:
> > >>On Feb 22 22:07, Lasse Collin wrote:
> > >>>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.
> > I think that sounds like a solution.
> I applied a matching patch for this:
> Please give it a try.

I applied the patches to the snapshot 20150223 and it works now. Thank

I'm going to release xz 5.2.1 in a day or two. Should that release have
a workaround for this Cygwin bug? The workaround would avoid using
O_NONBLOCK on stdout. It adds a race condition to signal handling in xz
but it's usually a very minor issue (xz 5.0.x has the race and no one
has complained). On the other hand, the fixes to the threading bugs are
somewhat important for xz too, so maybe I should just add a note that
xz 5.2.x isn't safe on Cygwin yet but will be in the (somewhat) near

On 2015-02-23 Corinna Vinschen wrote:
> 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"...

I agree, keeping it that way would be nice.

Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list