Hi,
On Wed, 21 Feb 2007, Junio C Hamano wrote:
> Junio C Hamano <junkio@xxxxxxx> writes:
>
> >> +static int verify_bundle(struct bundle_header *header)
> >> +{
> >> + /*
> >> + * Do fast check, then if any prereqs are missing then go line by line
> >> + * to be verbose about the errors
> >> + */
> >> + struct ref_list *p = &header->prerequisites;
> >> + const char *argv[5] = {"rev-list", "--stdin", "--not", "--all", NULL};
> >> + int pid, in, out, i, ret = 0;
> >> + char buffer[1024];
> >> +
> >> + in = out = -1;
> >> + pid = fork_with_pipe(argv, &in, &out);
> >> + if (pid < 0)
> >> + return error("Could not fork rev-list");
> >> + if (!fork()) {
> >> + for (i = 0; i < p->nr; i++) {
> >> + write(in, sha1_to_hex(p->list[i].sha1), 40);
> >> + write(in, "\n", 1);
> >> + }
> >> + close(in);
> >> + exit(0);
> >> + }
> >> + close(in);
> >
> > What if write() fails? That can happen when one of the objects
> > you feed here, or its parent objects, is missing from your
> > repository -- receiving rev-list would die() and the writing
> > child would sigpipe.
> >
> > I also wonder who waits for this child...
>
> In general, fork() to avoid bidirectional pipe deadlock is a
> good discipline, but in this particular case I think it would be
> easier to handle errors if you don't (and it would save another
> process). The other side "rev-list --stdin --not --all" is
> running a limited traversal, and would not emit anything until
> you stop feeding it from --stdin, or until it dies because you
> fed it a commit that does not exist. So as long as you check
> the error condition from write() for EPIPE to notice the other
> end died, I think you are Ok.
Thinking about this deeper, I have to say I find my decision to use
"--stdin" rather silly, given that I know the exact number of revisions,
and their SHA1s.
But it might make more sense to rewrite the checking part, instead of
fork()ing it.
Ciao,
Dscho
-
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