Re: What's cooking in git.git (Apr 2012, #06; Sun, 15)

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Apr 19, 2012, 13:48 UTC
Message-ID: <4F9017BF.90702@viscovery.net>
In-Reply-To: <CABPQNSb9BSfmGu2bYtZUndgkTom=r+Ho_CKsDr7wo=jfxiXEjA@mail.gmail.com>

Am 4/19/2012 15:31, schrieb Erik Faye-Lund:

Show 10 quoted lines

> int main(int argc, const char *argv[])
> {
>         int i, fd = open(__FILE__, O_RDONLY);
>         for (i = 0; i < 2; ++i) {
>                 char buf[11] = {0};
>                 mingw_pread(fd, buf, 10, 0);
>                 printf("buf = '%10s'\n", buf);
>         }
>         return 0;
> }

The test is flawed. It shows only that pread can read twice the same file location. But it must not update the file pointer, whereas the documentation of ReadFile says (quoting the paragraph that is relevant for us):

  If hFile is not opened with FILE_FLAG_OVERLAPPED and lpOverlapped is
  not NULL, the read operation starts at the offset that is specified in
  the OVERLAPPED structure. ReadFile does not return until the read
  operation is complete, and then the system updates the file pointer.

Hence, your mingw_pread() looks like a workable solution for our purposes, but is still not a 100% correct emulation of pread(). (Testing all this will have to wait for another 18 hours or so.)

Show 7 quoted lines

> Yeah. Other platforms are still an issue. You didn't address those
> either in your patch, even though it would be possible to modify it to
> deal with them by checking the NO_PREAD and NO_PTHREADS defines.
> 
> But they would still have the problem with the file-pointer racing for
> non-pread operations. Perhaps simply disabling threading is the better
> choice for these?

I think it is better to keep threading on in general, but only disable it for index-pack. Why should existing users take a performance hit?

-- Hannes