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

quoted

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.

quoted

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