Stefan Beller <sbeller@xxxxxxxxxx> writes: > 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.) It seems that by "list of stacks per thread", you mean "there is a list of stacks, each thread uses one and only element of that list", but I do not think it would be desirable. "Each thread only looks at one check at a time" is false. For example, "write_archive_entry()" would use one check that is specific to "git archive" to learn about "export-ignore" and "export-subst" attributes, while letting convert_to_write_tree() called via sha1_file_to_archive() called via write_entry() method (i.e. write_tar_entry() or write_zip_entry()) to use a separate check that is specific to the convert.c API. >> 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. I would still think it is a good first step. It may already be thread-safe, but may not be thread-ready from performance point of view. IOW, this would not yet help an attempt to make the callers faster by making them multi-threaded.