Stefan Beller <[email protected]> writes: > strbuf_read_once can also operate on blocking file descriptors if we are > sure they are ready. The poll (2) command however makes sure this is the > case. > > Reading the manual for poll (2), there may be spurious returns indicating > readiness but that is for network sockets only. Pipes should be unaffected.
Given the presence of "for example" in that bug section, I wouldn't say "only" or "should be unaffected". > By having this patch, we rely on the correctness of poll to return > only pipes ready to read. We rely on two things. One is for poll to return only pipes that are non-empty. The other is for read from a non-empty pipe not to block. > > This fixes compilation in Windows. > > Signed-off-by: Stefan Beller <[email protected]> > --- Thanks. Let's apply these fixes on sb/submodule-parallel-fetch, merge the result to 'next' and have people play with it. > run-command.c | 13 ------------- > 1 file changed, 13 deletions(-) > > diff --git a/run-command.c b/run-command.c > index 0a3c24e..51d078c 100644 > --- a/run-command.c > +++ b/run-command.c > @@ -1006,17 +1006,6 @@ static void pp_cleanup(struct parallel_processes *pp) > sigchain_pop_common(); > } > > -static void set_nonblocking(int fd) > -{ > - int flags = fcntl(fd, F_GETFL); > - if (flags < 0) > - warning("Could not get file status flags, " > - "output will be degraded"); > - else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK)) > - warning("Could not set file status flags, " > - "output will be degraded"); > -} > - > /* returns > * 0 if a new task was started. > * 1 if no new jobs was started (get_next_task ran out of work, non critical > @@ -1052,8 +1041,6 @@ static int pp_start_one(struct parallel_processes *pp) > return code ? -1 : 1; > } > > - set_nonblocking(pp->children[i].process.err); > - > pp->nr_processes++; > pp->children[i].in_use = 1; > pp->pfd[i].fd = pp->children[i].process.err; -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
