Re: [PATCH 10/23] files_ref_store: put the packed files lock directly in this struct
- From
Jeff King <peff@peff.net>
- Date
- May 17, 2017, 13:17 UTC
- Message-ID
- <20170517131753.rditx62clmkrdmeq@sigill.intra.peff.net>
- In-Reply-To
- <dd7637060bac1a27e03563edc82649812dcf897c.1495014840.git.mhagger@alum.mit.edu>
On Wed, May 17, 2017 at 02:05:33PM +0200, Michael Haggerty wrote:
Show 7 quoted lines
> 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 anyway.
-Peff