Re: [RFC/PATCH] attr: Document a new possible thread safe API

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 5, 2016, 17:00 UTC
Message-ID: <xmqq8tu2ras4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaFx++yipGmq=D2EPN4Gw9JhRXf_i4pFivTnkJmJXjFfg@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

> I thought about that, but as I concluded that the get_all_attrs doesn't need
> conversion to a threading environment, we can keep it as is.

I agree that it is OK for get_all_attrs() to use its own way to ask a question and receive an answer to it, that is different from how git_check_attr() asks its question. The threading-support for it is an unrelated issue, though (not that I think it needs to be run from a multi-threaded caller).

Show 20 quoted lines

>> ...  I'd expect the most
>> typical caller to be
>>
>>         static struct git_attr_check *check;
>>         struct git_attr_result result[2]; /* we want two */
>>
>>         git_attr_check_initl(&check, "crlf", "ident", NULL);
>>         git_check_attr(path, check, result);
>>         /* result[0] has "crlf", result[1] has "ident" */
>>
>> or something like that.
>
> I see, that seems to be a clean API. So git_attr_check_initl
> will lock the mutex and once it got the mutex it can either
> * return early as someone else did the work
> * needs to do the actual work
> and then unlock. In any case the work was done.
>
> git_check_attr, which runs in all threads points to the same check,
> but gets the different results.

Yeah, something along that line. It seems that we are now on the same page?

Thanks.