Stefan Beller <sbeller@xxxxxxxxxx> writes:
>>> Well all of the hunks in the patch are not threaded, so they
>>> don't follow a threading pattern, but the static pattern to not be
>>> more expensive than needed.
>>
>> Is it too invasive a change to make them as if they are thread-ready
>> users of API that happen to know their callers are not threading?
>> It would be ideal if we can prepare them so that the way they
>> interact with the attr subsystem will not have to change after this
>> step.
>
> As far as I see the future, we do not need to change those in the future,
> unless we add the threading to the current callers, which is usually a very
> invasive thing?
It does not matter how invasive the thread set-up and teardown that
happens in the callers.
I am talking about the part of _THIS_ code that you are updating,
that interacts with attr API. The way they prepare "check" and
"result", the way they ask questions by calling git_check_attr()
function.
Think of a thread-safe library function (like malloc()). If you
write
func (...) {
buf = malloc(20);
...
free(buf);
}
in a function that happens to be only called in a non-threaded
program today, you do not have to update these calls to malloc(3)
and free(3) when you update the callchain to threadable, right?
That kind of thread-preparedness is what I am trying to see if we
can achieve with this update.