On Thu, Nov 14, 2019 at 10:15:52AM -0800, Jonathan Tan wrote: > > > > A pthread_rwlock would work, but it would be the first use in Git. I > > > > think we'd need to find an equivalent for compat/win32/pthread.h. > > > > > > These[1][2] seems to be the equivalent options on Windows. I'll have > > > to read these docs more carefully, but [2] seems to be more > > > interesting in terms of speed. Also, the extra features of [1] are not > > > really needed for our use case here. > > > > > > [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/reader-writer-spin-locks > > > [2]: https://docs.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks > > > > Yeah, looks like it, but I don't have any expertise there (nor a Windows > > system to test on). > > One thing to note is that that if we do this, we'll be having one rwlock > per pack window. I couldn't find out what the Windows limits were, but > it seems that pthreads does not mandate having no limit [1]: Yeah, interesting point. We shouldn't _usually_ have too many windows at once, but I think this would be the first place where we allocate a non-constant number of thread mechanisms. And there are degenerate cases where you might have tens of thousands of packs. I suspect it's a non-issue in practice, though. Any limits there are likely related to kernel resources like descriptors. And those degenerate cases already run into issues there (did you know that Linux systems limit the number of mmaps a single process can have? I didn't until I tried repacking a repo with 35,000 packs). -Peff
