Re: [PATCH 10/23] files_ref_store: put the packed files lock directly in this struct
- Date: Wed, 17 May 2017 17:05:49 +0200
- From: Michael Haggerty <mhagger@xxxxxxxxxxxx>
- Subject: Re: [PATCH 10/23] files_ref_store: put the packed files lock directly in this struct
On 05/17/2017 03:17 PM, Jeff King wrote:
> On Wed, May 17, 2017 at 02:05:33PM +0200, Michael Haggerty wrote:
>> Instead of using a global `lock_file` instance for the main
>> "packed-refs" file and using a pointer in `files_ref_store` to keep
>> track of whether it is locked, embed the `lock_file` instance directly
>> in the `files_ref_store` struct and use the new
>> `is_lock_file_locked()` function to keep track of whether it is
>> locked. This keeps related data together and makes the main reference
>> store less of a special case.
> This made me wonder how we handle the locking for ref_stores besides the
> main one (e.g., for submodules). The lockfile structs have to remain
> valid for the length of the program. Previously those stores could have
> xcalloc()'d a lockfile and just leaked it. Now they'll need to xcalloc()
> and leak their whole structs.
> I suspect the answer is "we don't ever lock anything except the main ref
> store because that is the only one we write to", so it doesn't matter
Correct. If that ever changes, we'll be ready!