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.
-
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