Re: Make the git codebase thread-safe
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 12, 2014, 23:05 UTC
- Message-ID
- <CAPc5daVcAq2jb2-R32HVEG_GY4=JZLG-AmgZKNdQMzZZX2LOCg@mail.gmail.com>
- In-Reply-To
- <CAHOQ7J8Q1905pVwx9QVib1BM-Xxg8vTL=hDUjT7garX++VXm3g@mail.gmail.com>
On Wed, Feb 12, 2014 at 12:27 PM, Stefan Zager <szager@chromium.org> wrote:
Show 10 quoted lines
> On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano <gitster@pobox.com> wrote: >> Stefan Zager <szager@chromium.org> writes: >> >> Calls to write (and preparation of data to be written) will then >> remain single-threaded, but it sounds like that codepath is not the >> bottleneck in your measurement, so.... > > Yes, I considered that as well. At a minimum, that would still > require attr.c to implement thread locking, since attribute files must > be parsed to look for stream filters. I have already done that work.
I would have imagined that use of the attribute system belongs to "write and preparation of data to be written" category, i.e. the single threaded part of the kludge I outlined.
> But I'm not sure it's the best long-term approach to add convoluted > custom threading solutions to each git operation as it appears on the > performance radar.
Yeah, it depends on how clean and non-intrusive an abstraction we can make. The kludge I outlined is certainly not very pretty.