On Fri, Jul 13, 2007 at 11:23:07AM -0700, Junio C Hamano wrote:
> The reason we do not use lk->next but instead check lk->on_list,
> and the reason why we do not remove the lock from the list, are
> described in 1084b845.
I'm afraid I'm still missing something:
1084b845 commit message:
We cannot remove the list element in commit_lock_file(); if we
are interrupted in the middle of list manipulation, the call to
remove_lock_file_on_signal() will happen with a broken list
structure pointed by lock_file_list, which would cause the cruft
to remain, so not removing the list element is the right thing
to do. Instead we should be reusing the element already on the
list.
We have a list
list--->A--->B--->C
and we overwrite one next pointer to remove an element, say B
list--->A-------->C
At what point is the list structure broken?
If you are worried that the interrupt could happen in the middle
of writing the pointer (could it?), then shouldn't you worry
about adding elements too?
skimo
-
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
