Hi Jake, About a year ago in commit 5049c3422d26b2b68877307c41b35d7e6aae3235, you attempted to solve a race in llvm-objcopy. What was the race? I ask because unless "last change wins" is the result you want, then the race isn't solved. The problem is that `sys::fs::rename` is just a thin wrapper around POSIX semantics, and replacing an existing file is not an error. Dave
I was able to dig up that this was reviewed in D59033, which was accidentally omitted from the commit message. But I can't recall/find any more context that you're looking for. (Not the author, but I reviewed it). Are you noticing race condition issues here, or just curious about the history? On Tue, Jun 23, 2020 at 5:26 AM David Zarzycki via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Jake, > > About a year ago in commit 5049c3422d26b2b68877307c41b35d7e6aae3235, you > attempted to solve a race in llvm-objcopy. What was the race? I ask because > unless "last change wins" is the result you want, then the race isn't > solved. The problem is that `sys::fs::rename` is just a thin wrapper around > POSIX semantics, and replacing an existing file is not an error. > > Dave > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200624/5427d3fc/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3856 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200624/5427d3fc/attachment.bin>
Hi Jordan, I'm looking into the fallout of a proposal I'm making to deprecate `sys::path::system_temp_directory`. That lead me to D59033, which then caused me to wonder what problem it was trying to solve. Dave On Wed, Jun 24, 2020, at 11:35 AM, Jordan Rupprecht via llvm-dev wrote:> I was able to dig up that this was reviewed in D59033, which was accidentally omitted from the commit message. But I can't recall/find any more context that you're looking for. (Not the author, but I reviewed it). Are you noticing race condition issues here, or just curious about the history? > > On Tue, Jun 23, 2020 at 5:26 AM David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi Jake, >> >> About a year ago in commit 5049c3422d26b2b68877307c41b35d7e6aae3235, you attempted to solve a race in llvm-objcopy. What was the race? I ask because unless "last change wins" is the result you want, then the race isn't solved. The problem is that `sys::fs::rename` is just a thin wrapper around POSIX semantics, and replacing an existing file is not an error. >> >> Dave >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > *Attachments:* > * smime.p7s-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200624/28e11256/attachment.html>