On 2013-06-28 04.46, Mark Levedahl wrote:
> On 06/27/2013 01:38 PM, Junio C Hamano wrote:
>> Torsten Bögershausen <tbo...@web.de> 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
> 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.
I testet "rj/cygwin-remove-cheating-lstat" with the "socket pipe" on top:
Then I run "rj/cygwin-remove-cheating-lstat" without "socket pipe",
(or in other words git.git/pu):
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html