Johannes Sixt <j6t@xxxxxxxx> writes: > Am 05.11.2015 um 19:17 schrieb Stefan Beller: >> 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. >> By having this patch, we rely on the correctness of poll to return >> only pipes ready to read. >> >> This fixes compilation in Windows. > > It certainly does (but I haven't tested, yet). But parallel processes > will not work because we do not have a sufficiently complete waitpid > emulation, yet. (waitpid(-1, ...) is not implemented.) > > However, I think that the infrastructure can be simplified even further > to a level that we do not need additional emulation on Windows. ;-) This is why I love this list (and in general not rushing any change too early to 'next'). > Which makes me think: Other users of start_command/finish_command work > such that they > > 1. request a pipe by setting .out = -1 > 2. start_command > 3. read from .out until EOF > 4. close .out > 5. wait for the process with finish_command > > But the parallel_process infrastructure does not follow this pattern. > It > > 1. requests a pipe by setting .err = -1 > 2. start_command > 3. read from .err > 4. wait for the process with waitpid > > (and forgets to close .err). EOF is not in the picture (but that is > not essential). Unrelated tangent. daemon is another one that uses start_command() but does not use finish_command(). > I suggest to change this such that we read from the children until EOF, > mark them to be at their end of life, and then wait for them using > finish_command (assuming that a process that closes stdout and stderr > will die very soon if it is not already dead). Hmm, interesting. This does match the normal "spawn, interact and wait" cycle for a single process much better. -- 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