On Sun, Aug 11, 2019 at 4:20 AM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Sat, 10 Aug 2019, Carlo Marcelo Arenas Belón wrote: > > cURL is very strict about its allocator being thread safe and so that might > > be an issue to look for. > > Looks good to me. it is not ready yet for using though, at minimum I have to fix the #ifdef so there is no risky of breaking someone's build because they happen to still be using and old enough cURL (ex: 7.10) there is also the risk that xmalloc might not be sufficiently thread safe (ex: when it triggers unuse_one_window() through the use of a try_to_free_routine in packfile.c but we could mitigate the risk for now by doing it only first #ifdef NED (I promise to take it out before it even gets to next, assuming Junio would trust me enough after the last blow up to even get it into pu) alternatively, getting some feedback from people that know that code better like Shawn, since I have to admit I haven't read it enough to be fully confident it is safe (although I believe it was enough, or I wouldn't had sent it for feedback otherwise) > Please note that this did not cause problems in Git for Windows. > Probably because we leave it to cURL to deallocate whatever it > allocated. unlike PCRE2 there is no layering violation to trigger > Still, it is a good idea to ask libcurl to use the same allocator as Git. and it should have a positive performance impact, which should be nice to look for. Carlo
