From: Pete Wyckoff <pw@padd.com>
To: Clemens Buchacher <drizzd@aon.at>
Cc: Stefano Lattarini <stefano.lattarini@gmail.com>,
Sverre Rabbelier <srabbelier@gmail.com>,
git@vger.kernel.org
Subject: Re: master: t5800-remote-helpers.sh hangs on test "pulling from remote remote"
Date: Sat, 21 Apr 2012 22:17:53 -0400 [thread overview]
Message-ID: <20120422021753.GB11892@padd.com> (raw)
In-Reply-To: <20120421233521.GB20473@ecki>
drizzd@aon.at wrote on Sun, 22 Apr 2012 01:35 +0200:
> Hi Pete,
>
> Thanks for solving the mystery.
>
> On Sat, Apr 21, 2012 at 04:15:24PM -0400, Pete Wyckoff wrote:
> >
> > Not sure yet what is the right way to fix this. And I don't know
> > if it's just git-remote-testgit that has the problem because it
> > forks an importer, or if other remote helpers would be similarly
> > affected.
> >
> > The easiest fix is to invoke "python -u" in
> > git-remote-testgit.py, or do
> >
> > sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
> >
> > But I'm not sure if this works on all systems.
>
> Which part are you worried about? Maybe the patch below is more
> portable?
Your way works. But it doesn't handle universal newlines. I
don't know if the windows platforms turn that on for stdio. In
fact, I'm not sure we should be worried about sys.stdin buffering
on windows at all.
> > We could also consider adding a handshake after "export", to give the
> > helper time to get ready.
>
> Not sure I understand. The helper is throwing away some input. It seems
> to me there is nothing one can do to prevent such brokeness.
The handshake would give the helper time to get its streams
straightened up. It would do something like:
read "export\n"
fork importer, listening to stdin
write "export-ready\n" to stdout
And git push would wait for the "export-ready" line before it
unleases the stream from fast-export. But as Sverre said, that's
a protocol change, which is more difficult. And maybe not
warranted if we think this can also be attributed to helper
brokenness.
I think we should reopen stdin like this to fix the problem now.
I'll investigate if it exists on windows too, and see if it is
possible to fix there too.
> It would be nice if the deadlock could be detected and if git would time
> out in such a case, instead of hanging forever. But rather long delays
> can also be the result of the remote helper legimitately waiting for
> data from a slow network.
Tough, generally.
-- Pete
> Clemens
> ---
>
> diff --git a/git-remote-testgit.py b/git-remote-testgit.py
> index 616e772..bdd1116 100644
> --- a/git-remote-testgit.py
> +++ b/git-remote-testgit.py
> @@ -135,6 +135,22 @@ def update_local_repo(repo):
> return repo
>
>
> +def read_line_fd(fd):
> + """Read from fd until end of line or EOF, and no further.
> + """
> +
> + line = ''
> +
> + while True:
> + c = os.read(fd, 1)
> + if c == '':
> + break
> + line += c
> + if c == '\n':
> + break
> +
> + return line
> +
> def do_import(repo, args):
> """Exports a fast-import stream from testgit for git to import.
> """
> @@ -149,7 +165,7 @@ def do_import(repo, args):
> refs = [ref]
>
> while True:
> - line = sys.stdin.readline()
> + line = read_line_fd(sys.stdin.fileno())
> if line == '\n':
> break
> if not line.startswith('import '):
> @@ -211,9 +227,7 @@ def read_one_line(repo):
> time.sleep(int(sleepy))
> debug("Awake, to readline")
>
> - line = sys.stdin.readline()
> -
> - cmdline = line
> + cmdline = read_line_fd(sys.stdin.fileno())
>
> if not cmdline:
> warn("Unexpected EOF")
> --
> 1.7.10
>
next prev parent reply other threads:[~2012-04-22 2:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-14 9:01 master: t5800-remote-helpers.sh hangs on test "pulling from remote remote" Stefano Lattarini
2012-04-14 20:14 ` Clemens Buchacher
2012-04-15 0:00 ` Stefano Lattarini
2012-04-15 1:11 ` Clemens Buchacher
2012-04-15 8:08 ` Stefano Lattarini
2012-04-15 10:59 ` Clemens Buchacher
2012-04-15 11:18 ` Stefano Lattarini
2012-04-15 11:45 ` Clemens Buchacher
2012-04-15 11:58 ` Stefano Lattarini
2012-04-15 12:09 ` Clemens Buchacher
2012-04-15 13:19 ` Stefano Lattarini
2012-04-15 12:51 ` Clemens Buchacher
2012-04-17 1:46 ` Sverre Rabbelier
2012-04-19 23:34 ` Pete Wyckoff
[not found] ` <4F9145A1.6020201@gmail.com>
2012-04-21 20:15 ` Pete Wyckoff
2012-04-21 23:35 ` Clemens Buchacher
2012-04-22 2:17 ` Pete Wyckoff [this message]
2012-04-21 23:45 ` [PATCH] git-remote-testgit: fix race when spawning fast-import Pete Wyckoff
2012-04-21 23:42 ` Clemens Buchacher
2012-04-22 2:16 ` Pete Wyckoff
2012-04-22 9:49 ` Clemens Buchacher
2012-04-22 4:50 ` Junio C Hamano
2012-04-22 20:30 ` [PATCHv2] " Pete Wyckoff
2012-04-23 2:40 ` Junio C Hamano
2012-04-23 11:35 ` Pete Wyckoff
2012-04-15 11:12 ` master: t5800-remote-helpers.sh hangs on test "pulling from remote remote" Stefano Lattarini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120422021753.GB11892@padd.com \
--to=pw@padd.com \
--cc=drizzd@aon.at \
--cc=git@vger.kernel.org \
--cc=srabbelier@gmail.com \
--cc=stefano.lattarini@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).