Re: [PATCH/RFC 6/7] refs: add update_refs for multiple simultaneous updates

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

 



Brad King <brad.king@xxxxxxxxxxx> writes:

> On 08/29/2013 01:39 PM, Junio C Hamano wrote:
>> Brad King <brad.king@xxxxxxxxxxx> writes:
>>> +	for (i=0; i < n; ++i) {
>> 
>> Style:
>> 
>> 	for (i = 0; i < n; i++) {
>
> Fixed.
>
>> Is it asking for AB-BA deadlock?  If so, is the caller responsible
>> for avoiding it?
>
> Since we don't actually block waiting for locks we won't really
> deadlock.

Ahh, OK.

> For Git's internal API I think we can document this in a comment so
> that update_refs does not have to sort.  Then we can add a new
> ref_update_sort function to sort an array of struct ref_update.
> The user-facing "update-ref --stdin" can then use ref_update_sort.

My immediate reaction was "is there a case where the caller knows
that it already has a sorted collection?".  The single caller you
are envisioning could collect the proposed updates to a string list
and dedup, I think, and the resulting list would then be already
sorted.

But it may not be a bad idea to keep the callers dumb and have this
function always sort, dedup, *and* fail inconsistent request.  Then
your original caller that just collects --stdin input can pass
possibly unsorted, duplicated and/or inconsistent request to the
function and have it do the sanity check.
--
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]