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

From: Jeff King <peff@peff.net>
Date: Aug 17, 2022, 05:39 UTC
Message-ID: <Yvx/FNlTx+DCiCOj@coredump.intra.peff.net>
In-Reply-To: <c7c6524c-4f02-10f6-1a58-738cef5aecf2@web.de>

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

Show 7 quoted lines

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