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.
>> 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?
>
Good point.
--
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