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
