Subject: Re: [PATCH 04/22] rollback_lock_file(): set fd to -1

From: Junio C Hamano <[email-masked]>
Date: Wed, 02 Apr 2014 09:58:15 -0700

Jeff King <[email-masked]> writes:

> On Tue, Apr 01, 2014 at 05:58:12PM +0200, Michael Haggerty wrote:
>
>> When rolling back the lockfile, call close_lock_file() so that the
>> lock_file's fd field gets set back to -1.  This could help prevent
>> confusion in the face of hypothetical future programming errors.
>
> This also solves a race. We could be in the middle of rollback_lock_file
> when we get a signal, and double-close. It's probably not a big deal,
> though, since nobody could have opened a new descriptor in the interim
> that got the same number (so the second close will just fail silently).
>
> Still, this seems like a definite improvement.

This is probably related to my comments on 2/22, but is "fd" the
only thing that has a non-zero safe value?  Perhaps lock_file_init()
that clears the structure fields to 0/NULL and fd to -1, and a
convenience function lock_file_alloc() that does xmalloc() and then
calls lock_file_init() may help us a bit when the lockfile structure
is reused?