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

[Johannes Sixt <j.sixt@viscovery.net>]

Am 4/19/2012 15:31, schrieb Erik Faye-Lund:
> 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.)

> 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