Stefan Beller <sbeller@xxxxxxxxxx> 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). >> ... 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.