Re: [PATCH v4 06/32] lockfile: unlock file if lockfile permissions cannot be adjusted
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Sep 12, 2014, 11:03 UTC
- Message-ID
- <5412D2F3.50404@alum.mit.edu>
- In-Reply-To
- <xmqqr3zkifl5.fsf@gitster.dls.corp.google.com>
On 09/10/2014 12:39 AM, Junio C Hamano wrote:
Show 13 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes: > >> If the call to adjust_shared_perm() fails, lock_file returns -1, which >> to the caller looks like any other failure to lock the file. So in >> this case, roll back the lockfile before returning so that the lock >> file is deleted immediately and the lockfile object is left in a >> predictable state (namely, unlocked). Previously, the lockfile was >> retained until process cleanup in this situation. > > ... which would mean that other processes can grab a lock on the > same file a bit earlier. Is there any negative implication caused by > that difference? I do not think of any but I could be missing > something.
I think the end effect would be the same as if another process had grabbed the lock a nanosecond before this process tried to do so. So assuming that callers handle that situation correctly, I don't think this change can cause any problems.
Michael
-- Michael Haggerty mhagger@alum.mit.edu