On Mon, Oct 24, 2016 at 12:07 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> Instead of having a global attr stack, attach the stack to each check. > > Two threads may be working on "git checkout", one "git_attr_check" > in convert.c may be used by them to learn the EOL conversion for > each path, and these threads are working in different parts of > worktree in parallel. The set of .gitattributes files each of these > threads wants to be cached at one time is tied to where in the > directory hierarchy the thread is working in. > > The view by API users would not have to change from the point on > since 27/36 or so, but I think attr_stack needs to become per > <check, thread> tuple when we are fully thread-ready for the above > reason. I looked for a platform independent way to get a thread id as a natural number, i.e. I want to get 1,2,3,... such that I could have just added list/array of attr stacks to each check, which would be the <check, thread> tuple you envision. However I think we do not really need it to be per check. If we had an easy portable way of getting such a thread id, I would have implemented a list of stacks per thread first. (Because each thread only looks at one check at a time.) So this is not a baby step because I did not want to do it all at once, but because I did not find a suitable API to use. > > But we need to start somewhere to move away from the current "one > single attr stack" to "there are multiple attr stacks", and this > "two checks may and do use different attr stacks" is probably a > reasonable first step. It may give a single-threaded API users > immediate benefit if the "read and keep only the entries relevant > to the query" optimization is done with this step alone, without > making the cache per <check, thread> pair. > >> This allows to use the attr in a multithreaded way. > > With manipulation of attr stack protected with a single Big > Attributes Lock, this should be safe. It may not perform very well > when used by multiple threads, though ;-) I agree. So maybe it is not really a good fit for general consumption yet.