Re: [PATCHv2] attr: convert to new threadsafe API

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2016, 20:59 UTC
Message-ID: <xmqqpon52shy.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaBhXHLDEK0XMLjm3QofmtaGZspA3EEx5x4-qCYY--wZA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 13 quoted lines

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