From: René Scharfe <l.s.r@web.de>
Date: Wed, 01 Oct 2014 11:27:49 GMT
Subject: Re: [PATCH v7 09/38] lock_file(): always initialize and register lock_file object
Message-ID: <542BE535.3040500@web.de>
In-Reply-To: <1412159322-2622-10-git-send-email-mhagger@alum.mit.edu>

Am 01.10.2014 um 12:28 schrieb Michael Haggerty:
> The purpose of this patch is to make the state diagram for lock_file
> objects simpler and deterministic.
>
> If locking fails, lock_file() sometimes leaves the lock_file object
> partly initialized, but sometimes not. It sometimes registers the
> object in lock_file_list, but sometimes not. This makes the state
> diagram for lock_file objects effectively indeterministic and hard to
> reason about. A future patch will also change the filename field into
> a strbuf, which needs more involved initialization, so it will become
> even more important that the state of a lock_file object is
> well-defined after a failed attempt to lock.
>
> The ambiguity doesn't currently have any ill effects, because
> lock_file objects cannot be removed from the lock_file_list anyway.
> But to make it easier to document and reason about the code, make this
> behavior inconsistent: *always* initialize the lock_file object and

s/incon/con/, certainly?

> *always* register it in lock_file_list the first time it is used,
> regardless of whether an error occurs.
>
> While we're at it, make sure that all of the lock_file fields are
> initialized to values appropriate for an unlocked object; the caller
> is only responsible for making sure that on_list is set to zero before
> the first time it is used.