Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file
- From
Stefan Beller <sbeller@google.com>
- Date
- Dec 5, 2014, 19:41 UTC
- 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:
Show 23 quoted lines
> 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