Re: [PATCH v7 09/38] lock_file(): always initialize and register lock_file object
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Oct 1, 2014, 11:38 UTC
- Message-ID
- <542BE7CA.5060902@alum.mit.edu>
- In-Reply-To
- <542BE535.3040500@web.de>
On 10/01/2014 01:27 PM, René Scharfe wrote:
Show 19 quoted lines
> 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?
Yes, thanks.
Junio, if another reroll is not necessary, would you mind fixing this when applying?
Michael
-- Michael Haggerty mhagger@alum.mit.edu