Re: [PATCHv2] run-command: detect finished children by closed pipe rather than waitpid

[Johannes Sixt <j6t@kdbg.org>]

Am 20.11.2015 um 23:05 schrieb Jonathan Nieder:
> Stefan Beller wrote:
>
>> Detect if a child stopped working by checking if their stderr pipe
>> was closed instead of checking their state with waitpid.
>> As waitpid is not fully working in Windows, this is an approach which
>> allows for better cross platform operation. (It's less code, too)
>
> Can you say more about what is broken about waitpid on Windows?

waitpid(-1, ...) is not implemented on Windows.

Is it necessary to mention waitpid here at all? The most compelling 
reason to write the infrastructure in this new way is that it is much 
more in line with the usual "start_command, read-until-EOF, 
finish_command" sequence.

> I ask because it's possible for a child to close stderr without
> intending to be finished.  That might be okay here (though the commit
> subject doesn't explain so, it is only affecting the workqueue
> interface that runs commands in parallel and not the normal
> run-command interface) but would need some documentation and could be
> counterintuitive.

It could be spelled out more clearly. The children have both their stdin 
and stdout redirected to the same writable end. On the parent side, we 
have to deal only with "stderr" simply because our child_process 
facility has everything to redirect like ">&2" (the stdout_to_stderr 
flag), but nothing for "2>&1".

Yeah, it's still possible that the child closes both stdout and stderr 
long before it dies, but that would really be far, far outside the norm.

> So if there's a simple way to get waitpid to work, that seems
> preferrable.

It would be possible, but not simple, to make waitpid on Windows 
suitable for the original code, but that does not make the original code 
preferrable.

-- Hannes