On Thu, Sep 30, 2010 at 21:10, Nate Parsons <parsons.nate@xxxxxxxxx> wrote:
> On Thu, Sep 30, 2010 at 4:15 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx> writes:
>> > FWIW I think this is more readable, but maybe we want to retry on all
>> > platforms:
>> >
>> > Â Â my $fh;
>> > Â Â if ($^O eq 'MSWin32' or $^O eq 'cygwin') {
>> > Â Â Â Â # Try 10 times to open our lock file, in case Windows is lagging
>> > Â Â Â Â for my $try (1..10) {
>> > Â Â Â Â Â Â sysopen($fh, $db_lock, O_RDWR | O_CREAT);
>> > Â Â Â Â Â Â last if $fh;
>> > Â Â Â Â }
>> > Â Â } else {
>> > Â Â Â Â sysopen($fh, $db_lock, O_RDWR | O_CREAT);
>> > Â Â }
>> >
>> > Â Â warn "Couldnt open $db_lock: $!\n" unless $fh;'
>
> I agree that this is more readable, although I don't think there needs
> to be separate code sections for each OS. If it's a good OS, it will
> only loop once. You would want to die or croak instead of warn,
> though. It needs the lock to continue, right?
Yes, right. Meant to write croak() not warn() there.
>> What exactly does "Windows is lagging" mean in the above?
>>
>> Why does sysopen() randomly fail and why does it succeed (sometimes) when
>> it immediately gets retried with the same argument? ÂIs this a shared lock
>> and is used by some other processes that drive git? ÂWhy does the issue
>> manifest only on Windows? ÂIf there are competing processes, wouldn't it
>> exacerbate the situation to run a tight loop to try grabbing the lock
>> without waiting, like the above patch does?
>
> All very good questions, and I don't know most of the answers. I know
> that sysopen() is just a thin wrapper around the 'open' system call,
> so the problem has to be with Windows somehow. It probably doesn't
> happen with other OSes because they're better at files :P
>
> I have verified (to the best of my ability) that this problem happens
> even when TortoiseGit is not running, and I don't have cheetah
> installed, and there are no other 'git.exe's running. I considered
> putting some sort of sleep() in there, but since it worked so well
> without the sleep (it only retried once at most). Fetching multiple
> revisions is slow anyways, so I don't think a 2-second wait would
> hurt, though.
Maybe this has to do with our assumptions about being on a POSIX
filesystem, doesn't Windows have different semantics if two processes
open the same file, or something?
Blah, I don't know. I'm about as clueless when it comes to Windows as
VMS :)
--
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