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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
