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

[Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx>]

On Thu, Apr 19, 2012 at 03:52:44PM +0200, Erik Faye-Lund wrote:
> On Thu, Apr 19, 2012 at 3:48 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote:
> > 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.
> 
> Oh, you are of course right. *slaps forehead*
> 
> > 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.
> 
> Indeed. Correcting the test to first do pread and then read reveals
> that the file pointer does indeed get updated. Grrr...
> 
> > 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.)
> >
> 
> I don't know our use-cases, but I'd be a lot happier if I could find a
> safe way to have it not update the file-pointer. Just reading it and
> setting it back again would be racy.

Replace pread() in index-pack to pread_weak() because we know we don't
care about file offset in index-pack. Define pread_weak as pread
normally. Windows port can provide its own pread_weak version, which
can freely move file offset.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html