On Sun, Aug 14, 2022 at 05:37:08PM +0200, René Scharfe wrote:

Turns out that's not the case on Windows: 94f4d01932 (mingw: workaround
for hangs when sending STDIN, 2020-02-17) changed the compatibility
implementation to 'Make `poll()` always reply "writable" for write end
of the pipe.'.

Ah, good find. That kind of explains everything, then, I think. ;)

quoted

I'm not sure what "small enough" we can rely on, though. Really it is
the interplay between poll() and write() that we care about here. We
would like to know at what point poll() will tell us it's OK to write().
But we don't know what the OS thinks of that.

Based on the output above I think Linux' poll() won't consider a pipe
writable that has less than PIPE_BUF (4096) available bytes.

Right, that makes sense. It would have to in order to meet the atomicity
requirement for write(), but still always make forward progress for each
write().

Perhaps we should take the advice about PIPE_NOWAIT in the docs serious
and use overlapping (asynchronous) writes on Windows instead.  This
would mean reimplementing the whole pipe_command() with Windows API
commands, I imagine.

I wouldn't be opposed to that, in the sense that it's supposed to be a
black box to the caller, and it's relatively small in size. But I think
we're pretty close to having something usable without that, so I'd like
to pursue a smaller fix in the interim.

Avoiding xwrite() in pump_io_round() on top lets the test suite
finish successfully.

That makes sense. We end up busy-looping between poll() and write()
while we wait for our read descriptor to become available. But if poll()
doesn't block, that's the best we can do.

-Peff