This is the mail archive of the
mailing list for the Cygwin project.
Re: Clearing O_NONBLOCK from a pipe may lose data
- From: Lasse Collin <lasse dot collin at tukaani dot org>
- To: cygwin at cygwin dot com
- Date: Tue, 24 Feb 2015 16:16:01 +0200
- Subject: Re: Clearing O_NONBLOCK from a pipe may lose data
- Authentication-results: sourceware.org; auth=none
- References: <20150222220747 dot 789401d2 at tukaani dot org> <20150223105653 dot GG437 at calimero dot vinschen dot de> <20150223122345 dot GM437 at calimero dot vinschen dot de> <54EC2566 dot 4030703 at towo dot net> <20150224110953 dot GF437 at calimero dot vinschen dot de>
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
I agree, keeping it that way would be nice.
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple