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

From: Johannes Sixt <j6t@kdbg.org>
Date: Nov 20, 2015, 23:24 UTC
Message-ID: <564FABA3.2040100@kdbg.org>
In-Reply-To: <20151120220544.GC18255@google.com>

Am 20.11.2015 um 23:05 schrieb Jonathan Nieder:

Show 8 quoted lines

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

Show 6 quoted lines

> 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