Re: [PATCH v2] pipe_command(): mark stdin descriptor as non-blocking

From: Jeff King <peff@peff.net>
Date: Aug 11, 2022, 08:52 UTC
Message-ID: <YvTDUWjmJKK/6c1s@coredump.intra.peff.net>
In-Reply-To: <dee6cce5-6f95-ecbe-1dd3-dd54f9746c67@web.de>

On Thu, Aug 11, 2022 at 12:35:02AM +0200, René Scharfe wrote:

Show 7 quoted lines

> > The key thing is that pump_io() is careful never to initiate a write()
> > unless poll() has just told us that the descriptor is ready for writing.
> 
> Right, and Windows breaks it by refusing to write data bigger than the
> buffer even if it's empty.
> 
> What does "ready for writing" mean?  PIPE_BUF bytes are free, right?

According to POSIX, it is "a write() will not block". ;)

I think in practice for Unix systems it means that at least 1 byte is available.

Show 10 quoted lines

> > If something unexpected happens there (i.e., the descriptor is not
> > really ready), a blocking descriptor is going to be stuck. And with
> > xwrite(), we're similarly stuck (just looping instead of blocking).
> > Without xwrite(), a non-blocking one _could_ be better off, because that
> > EAGAIN would make it up to pump_io(). But what is it supposed to do? I
> > guess it could go back into its main loop and hope that whatever bug
> > caused the mismatch between poll() and write() goes away.
> 
> It should check other fds to let the other side make some progress on
> them, so that it eventually gets to drain the pipe we want to write to.

Yes, that "go back into its main loop" would do that. But that's not guaranteed to produce progress any time soon. We may just busy-loop between poll() and write() returning EAGAIN if another descriptor isn't ready. And if the thing preventing further writes is something the process on the other side of the pipe can't fix (and thus we in turn can't help it fix things by doing a read()), then we'll loop forever. Which (if I understand it) is exactly the case here because the underlying code refused to do a partial write.

-Peff