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/
