Re: [RFC/PATCH] pipe_command(): mark stdin descriptor as non-blocking

From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [RFC/PATCH] pipe_command(): mark stdin descriptor as non-blocking
Date: Tue, 2 Aug 2022 11:39:57 -0400	[thread overview]
Message-ID: <YulFTSTbVaTwuQtt@coredump.intra.peff.net> (raw)
In-Reply-To: <YuikU//9OrdpKQcE@coredump.intra.peff.net>

On Tue, Aug 02, 2022 at 12:13:07AM -0400, Jeff King wrote:

>   - more importantly, I'm not sure of the portability implications of
>     the fix. This is our first use of O_NONBLOCK outside of the
>     compat/simple-ipc unix-socket code. Do we need to abstract this
>     behind a compat/ layer for Windows?

So I think the answer is pretty clearly "yes", from the Windows CI
results:

  run-command.c:1429:18: 'O_NONBLOCK' undeclared (first use in this function)
         flags |= O_NONBLOCK;
                  ^~~~~~~~~~

It looks like we'd have the option of either adding F_GETFL/F_SETFL
support to compat/mingw.c's fake fcntl() function, or adding a
compat/nonblock.c that abstracts the whole thing. I'd prefer the latter,
as it makes the interface a bit narrower.

But I'm not sure what should go on the Windows side of that #ifdef.
Unlike some other spots, I don't think we can just make it a noop, or
Windows will be subject to the same deadlock (unless for some reason its
write() does behave differently?).

-Peff