Re: [PATCH v2 05/11] object-store: allow threaded access to object reading
- From
Jeff King <peff@peff.net>
- Date
- Nov 14, 2019, 06:01 UTC
- Message-ID
- <20191114060134.GB10643@sigill.intra.peff.net>
- In-Reply-To
- <CAHd-oW4PtO2CKpd3HFgrJWmQf3MN+MHt5c7V6OGx33LgU-CrOQ@mail.gmail.com>
On Thu, Nov 14, 2019 at 02:57:42AM -0300, Matheus Tavares Bernardino wrote:
Show 7 quoted lines
> 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.
Show 10 quoted lines
> > 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