Michael Haggerty 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.
On 04/02/2014 06:58 PM, Junio C Hamano wrote:
> Jeff King 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 i
Jeff King 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.
>
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. W
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.
Signed-off-by: Michael Haggerty
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
5 matches
Mail list logo