On Sun, Sep 08, 2019 at 02:18:15PM +, Douglas Graham wrote:
> When I collected that strace output, I had stdout redirected to a pipe to my
> workaround program, but I did not redirect stderr. So ssh made stdout
> non-blocking,
> but since stderr was still connected to my terminal, it didn't
I think I've just figured out why my workaround works. When ssh sets O_NONBLOCK
on stdout, it's setting it on the write side of the pipe that git created.
Nothing
else writes to that pipe, so this does not cause a problem. Presumably, ssh
itself
is able to deal with writing to a non-blocking "
Thanks for giving this some thought.
> I don't think this can directly be the culprit, because that ssh's stdout
> will be
> hooked to a pipe talking to Git, not to the original stdout of "git fetch". It
> should not have even received a descriptor that is a copy of the original
> stdout (nor std
On Sat, Sep 07, 2019 at 11:50:41PM +, Douglas Graham wrote:
> We have a parallel build that occasionally fails with the error message
> "make: write error". Make prints that error message as it is exiting when
> it detects that it has seen errors while writing to stdout. The error it
> is en
We have a parallel build that occasionally fails with the error message
"make: write error". Make prints that error message as it is exiting when
it detects that it has seen errors while writing to stdout. The error it
is enountering is an EAGAIN error, which implies that something has made
its s
5 matches
Mail list logo
