Re: [PATCH 49/83] builtin/apply: move 'lock_file' global into 'struct apply_state'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 25, 2016 at 9:50 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>> @@ -4515,8 +4521,6 @@ static int write_out_results(struct apply_state *state, struct patch *list)
>>         return errs;
>>  }
>>
>> -static struct lock_file lock_file;
>
> Does the static lock_file in build_fake_ancestor() deserve the same
> sort of treatment? (I haven't traced the code enough to answer this.)

Maybe yes we could do the same thing for this static lock_file, but
this can be done later, and it could be a bit involved, so I prefer to
not touch that for now.

We are using the lock_file like this in build_fake_ancestor():

    hold_lock_file_for_update(&lock, filename, LOCK_DIE_ON_ERROR);
    if (write_locked_index(&result, &lock, COMMIT_LOCK))
        return error("Could not write temporary index to %s", filename);

so it looks like it is safe to call build_fake_ancestor() many times
as long as it is not called by different threads.
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]