Michael Haggerty <mhag...@alum.mit.edu> writes: > The first use of a lock_file object necessarily passes through > lock_file(). The only precondition for that function is that the > on_list field is zero, which is satisfied by a xcalloc()ed object. > > Subsequent uses of a lock_file object must *not* zero the object. > lock_file objects are added to the lock_file_list and never removed. So > zeroing a lock_file object would discard the rest of the linked list. > But subsequent uses must also pass through lock_file(), which sees that > on_list is set, and assumes that the object is in a self-consistent > state as left by commit_lock_file() or rollback_lock_file(). > > At least that's how it is supposed to work. But lock_file objects are > in fact not cleaned up correctly in all circumstances. The next version > of this patch series will work to fix that.
Thanks; I see the next round already posted to the list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
