From: Stefan Beller <sbeller@google.com>
Date: Fri, 05 Dec 2014 19:41:05 GMT
Subject: Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file
Message-ID: <CAGZ79kbf_Ze6JR33Y6-N3JZTUQqTyqc-feQZ-__h7JkeUTzUvg@mail.gmail.com>
In-Reply-To: <xmqqoarhq4dc.fsf@gitster.dls.corp.google.com>

On Fri, Dec 5, 2014 at 11:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>>> > +static struct lock_file reflog_lock;
>>>
>>> If this lockfile is only used in that one function, it can be declared
>>> inside the function.
>>>
>>> If it is meant to be used throughout the 'git reflog' command, then it
>>> can go near the top of the file.
>>>
>>
>> After the series completes, this lock is only used in reflog_expire.
>> So I'd rather move it inside the function? Then we could run the reflog_expire
>> function in parallel for different locks in theory?
>
> I am not sure about the "parallel" part, but I would imagine that it
> is an essential prerequisite to move this outside the "client" code
> if we want to later replace the backing storage of refs and reflogs
> outside the filesystem, so from that point of view,  I think the
> suggestion makes sense.
>
> Thanks.
>

Sorry for the confusion. With parallel I mean, that in theory we could have
multiple threads running reflog expire at the same time in the same program.
Having the "static struct lock_file reflog_lock;" around, we can only
process one
reflog at a time, as that is holding the lock_file struct.

I am not saying we want to go multi-threading any time soon if at all.
Just that it would
be easier to do, if not having the lock file as a file-global variable
instead of a
variable inside a function.

Thanks,
Stefan