Re: [GSoC][RFC] Proposal: Make pack access code thread-safe

From: Philip Oakley <philipoakley@iee.org>
Date: Apr 8, 2019, 19:19 UTC
Message-ID: <1348d823-9729-a5eb-2104-df7c4a41911d@iee.org>
In-Reply-To: <CAHd-oW5PFmj4u2YB-1TcHWNxkokfCEsUq_zB=Rx2Vmdk5Z9eMw@mail.gmail.com>

Hi Matheus

On 08/04/2019 18:04, Matheus Tavares Bernardino wrote:

Show 5 quoted lines

>> Another "32-bit problem" should also be expressly considered during the
>> GSoC work because of the MS Windows definition of uInt / long to be only
>> 32 bits, leading to much of the Git code failing on the Git for Windows
>> port and on the Git LFS (for Windows) for packs and files greater than
>> 4Gb.https://github.com/git-for-windows/git/issues/1063

Show 7 quoted lines

> Thanks for pointing it out. I didn't get it, thought, if your
> suggestion was to also propose tackling this issue in this GSoC
> project. Was it that? I read the link but it seems to be a kind of
> unrelated problem from what I'm planing to do with the pack access
> code (which is tread-safety). I may have understood this wrongly,
> though. Please, let me know if that's the case :)
>

The main point was to avoid accidental regressions by re-introducing simple 'longs' where memsized types were more appropriate.

Torsten has already done a lot of work at https://github.com/tboegi/git/tree/tb.190402_1552_convert_size_t_only_git_master_181124_mk_size_t

HTH Philip (I'm off line for a few days)