Re: [PATCH] mingw: handle writes to non-blocking pipe

[Jeff King <peff@peff.net>]

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. ;)

> > 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