On 09/10/2014 12:39 AM, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html