Re: 1.5.20(0.156/4/2) pipe hangs, dos files

[Darryl Miles <darryl-mailinglists at netbauds dot net>]

Saurabh Tendulkar wrote:
> We have an older cygwin on another machine: CYGWIN_NT-5.1 1.5.6(0.108/3/2),
> paste (textutils) 2.0.21, Gnu Awk 3.1.3, which runs absolutely fine.
>
> ulimit -p is 8 on both machines.

Is this problem related to the select() code pipe problems.


This is where the writability/select event semantics do not follow POSIX 
convention.  This is specifically a problem to pipes in blocking mode 
who rely on the behaviour to stop I/O deadlocks occuring.

CYGWIN can indicate a writability event on a pipe which will block the 
next time you write to it.  The application program is not expecting it 
to block and so hangs.

The reason for the volume of data needing to be over a threshold is that 
you need to fill the pipe buffer space to cause a blocking condition to 
occur.


I did take a look at it a few weeks ago, there is code in the select.cc 
which should do the trick.  However this was disabled because one (or 
more) users of a specific application ("unison") found it to be causing 
problems with their program.  So the lastest attempt to fix this gaping 
problem was disabled, rather than having the application affected 
reviewed and a testcase created to exhibit the problem they see.

We already have a test case to prove the current CYGWIN library IO 
semantics fail.

But we dont have a test case to prove how the commented out code in 
select.cc failed for the application ("unison")  that was affected.


So we are currently stuck in the middle.  Where one group of users (who 
do have a provable test case) for which select() is broken are suffering 
because we dont understand and can't see what the problem was with other 
groups of users affected application.  This could be viewed at "The Lazy 
minority rules".  Lazy as in unison users didn't not bother to provice a 
testcase to prove where CYGWIN has broken, and Minority in that more 
popular uses remain broken.

The only mitigating circumstances are that the minority application 
users could cite that previous version of CYGWIN has worked.  But this 
should not have been justifiable grounds to reinstate


We have to face it that it is broken either way so no one way has more 
weight than another when you are en-route to finding the fix.


I am still interested in tackling the whole situation but I do need to 
be furnished with a testcase to work with.  I believe the original 
comeback by the group of users running "unison" should have insisted a 
testcase was produced by them to demonstrate the new breakage.

At the moment in time I do not understand and can not see how the 
minority application was affected by the current proposed fix.


Darryl

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/