On 2013-06-28 04.46, Mark Levedahl wrote: > On 06/27/2013 01:38 PM, Junio C Hamano wrote: >> Torsten Bögershausen <tboegi@xxxxxx> writes: >> >>> Work around issues that git hangs when doing fetch or pull under >>> various protocols under CYGWIN. >>> >>> Replace pipe() with a socket connection using a TCP/IP. >>> Introduce a new function socket_pipe() in compat/socket_pipe.c >> Sounds like sweeping the real problem, whatever it is, under rug. >> Is it that we are assuming a pipe buffer that is sufficiently large >> and expecting a write that we deem to be small enough not to block, >> causing a deadlock on a platform with very small pipe buffer, or >> something? >> > > There were issues in early v1.7 Cygwin release for overlapping I/O such that the pipe was sometimes terminated early resulting in data loss. If the pipe implementation in Cygwin is still a problem a good test case sent to the Cygwin developers would be the right approach rather than a one-off patch in git to try to work around a current platform bug. > > Note - I do not see random hangs with the stat/lstat hack removed, rather the sole test suite hang I see is repeatable in t0008.sh. So, if the patch remains, we may be able to run this remaining hang to ground. > > Mark Thanks, I testet "rj/cygwin-remove-cheating-lstat" with the "socket pipe" on top: no hanging. Then I run "rj/cygwin-remove-cheating-lstat" without "socket pipe", (or in other words git.git/pu): No hanging. Then I run a "stress test" with many (but not all) "git fetch" tests: t1507, t1514, t2015, t2024, t3200, t3409, t3600, t4041, t6050, t6200 repeat those tests in a forever loop. All these test run 24 hours in a row on a single core machine, no hanging. (I need to re-do the test on a dual-core machine) So at the moment I don't have any problems to report for cygwin, which is good. And it looks as if "rj/cygwin-remove-cheating-lstat" prevents the "hanging", so there is another +1 to keep it and move it into next. /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html