Re: [PATCH 10/23] files_ref_store: put the packed files lock directly in this struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
anyway.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]