Re: git.git as of tonight
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Nov 3, 2015, 21:03 UTC
- Message-ID
- <56392106.1010401@kdbg.org>
- In-Reply-To
- <CAGZ79kbAj-tZS3X1EwFw_gGh1=YU8M0OmEX91W8f++fqs6TiBA@mail.gmail.com>
Am 03.11.2015 um 19:18 schrieb Stefan Beller:
> ... ReadFileEx ... "overlapped" operation.
Let's not go there just yet.
Show 11 quoted lines
>> 1. Make this an optional feature so that platforms can compile it >> out, if it is not already done. My preference, even if we go >> that route, would be to see if we can find a way to preserve the >> overall code structure (e.g. instead of spawning multiple >> workers, which is why the code needs NONBLOCK to avoid getting >> stuck on reading from one while others are working, perhaps we >> can spawn only one and not do a nonblock read?). > > Yeah that would be my understanding as well. If we don't come up with > a good solution for parallelism in Windows now, we'd need to make it at > least working in the jobs=1 case as well as it worked before.
That should be possible. I discovered today that we have this function:
static void set_nonblocking(int fd)
{
int flags = fcntl(fd, F_GETFL);
if (flags < 0)
warning("Could not get file status flags, "
"output will be degraded");
else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK))
warning("Could not set file status flags, "
"output will be degraded");
}Notice that it is not a fatal condition if O_NONBLOCK cannot be established. (BTW, did you ever test this condition?) If we add two lines (which remove the stuff that does not work on Windows) like this:
static void set_nonblocking(int fd)
{
#ifndef GIT_WINDOWS_NATIVE
int flags = fcntl(fd, F_GETFL);
if (flags < 0)
warning("Could not get file status flags, "
"output will be degraded");
else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK))
#endif
warning("Could not set file status flags, "
"output will be degraded");
}we should get something that works, theoretically. We still need a more complete waitpid emulation, but that does not look like rocket science. I'll investigate further in this direction.
-- Hannes