On Thu, Nov 14, 2019 at 02:57:42AM -0300, Matheus Tavares Bernardino wrote: > About the other parallel inflation calls on loose objects at > unpack_loose_short_header(), unpack_loose_header_to_strbuf() and > unpack_loose_rest(): could they suffer from a similar race problem? > FWIU, the inflation input used in these cases comes from > map_loose_object(), and it's not referenced outside this scope. So I > think there's no risk of one thread munmapping the object file while > other is inflating it. Is that right? Right, I think loose objects would be fine, because the mmap'd content is local to that stack variable. > > 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). -Peff
