summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: c2c6d93)
raw | patch | inline | side by side (parent: c2c6d93)
author | H. Peter Anvin <hpa@zytor.com> | |
Tue, 27 Mar 2007 23:45:06 +0000 (16:45 -0700) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Thu, 29 Mar 2007 08:41:23 +0000 (01:41 -0700) |
Right now, we don't close the read end of the pipe when git-upload-pack
runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
instead of dying with SIGPIPE if the latter dies, which seems to be the
norm if the client disconnects.
Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
pointing out where this close() needed to go.
This patch has been tested on kernel.org for several weeks and appear
to resolve the problem of git-upload-pack processes hanging around
forever.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from commit 465b3518a9ad5080a4b652ef35fb13c61a93e7a4)
runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
instead of dying with SIGPIPE if the latter dies, which seems to be the
norm if the client disconnects.
Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
pointing out where this close() needed to go.
This patch has been tested on kernel.org for several weeks and appear
to resolve the problem of git-upload-pack processes hanging around
forever.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from commit 465b3518a9ad5080a4b652ef35fb13c61a93e7a4)
upload-pack.c | patch | blob | history |
diff --git a/upload-pack.c b/upload-pack.c
index 3648aae1a777aec4bba77b40b9cf6da484190441..044c33b09091eefff4f6035286c0b4bd4adf155e 100644 (file)
--- a/upload-pack.c
+++ b/upload-pack.c
int i;
struct rev_info revs;
+ close(lp_pipe[0]);
pack_pipe = fdopen(lp_pipe[1], "w");
if (create_full_pack)