Re: [PATCH v6 27/39] try_merge_strategy(): use a statically-allocated lock_file object

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

 



Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:

> Even the one lockfile object needn't be allocated each time the
> function is called.  Instead, define one statically-allocated
> lock_file object and reuse it for every call.
>
> Suggested-by: Jeff King <peff@xxxxxxxx>
> Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
> ---
> ...
> -	hold_locked_index(lock, 1);
> +	hold_locked_index(&lock, 1);
>  	refresh_cache(REFRESH_QUIET);
>  	if (active_cache_changed &&
> -	    write_locked_index(&the_index, lock, COMMIT_LOCK))
> +	    write_locked_index(&the_index, &lock, COMMIT_LOCK))

I wondered if the next step would be to lose the "lock" parameter
from {hold,write}_locked_index() and have them work on a
process-global lock, but that would not work well.

The reason why this patch works is because we are only working with
a single destination (i.e. $GIT_INDEX_FILE typically .git/index),
right?

Interesting.


--
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]