On 8/1/06, Darryl Miles wrote:
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.
As I recall, the "group of users running unison" was the exact same group as the group who developed the currently-commented-out code in select.cc, so there wasn't any particular need for them to provide themselves a test case.... I'm sure it's all explained in the mailing list archives. Basically, the NtQueryInformationFile() gives back the amount of non-paged pool used by the pipe, which is only the same thing as the amount of data available to read in the case that there are no outstanding read()s on the pipe. Otherwise, the commented-out code can cause a write()r to deadlock any time the process at the other end of the pipe issues a read() for more than a pipe buffer's worth of data. This is much worse than the current situation, where a non-blocking write can occasionally block, which in turn may cause (serious) performance issues but rarely a total deadlock. (After all, cygwin is not an rtos and there is allowed to have arbitrary delays at any point in the code, without violating the posix semantics, so long as eventually the write() *eventually* returns.) L -- 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/
