On 07.05.2020 21:45, Joerg Sonnenberger wrote: > On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote: >> Lack of libatomic is increasingly hard to deal with. This library >> implements function calls for atomic operations. > > I'm sure you have done the research on why the existing arguments > against providing libatomic are wrong. For some reasons, you have missed > including them in your email. > 1. Usually slower than cpu instructions as there are syscalls involved. 2. Not safe for shared memory scenarios between multiple applications. Both are no issue in real life as otherwise NetBSD wouldn't be the (almost?) only leftover without libatomic. Coincidentally futexes share the same arguments against multiprocess operation. >> Personally I stopped testing sanitizers year ago as they required >> libatomic. We want libatomic for LLDB in base. Rewritting everything to >> stop using libatomic is no viable as this is a standard C11/C++14 feature. > > LLDB doesn't need libatomic. It needs a patch to fix the timer > implementation to not require 64bit atomics. Which is exactly one of the > original points that libatomic hides major performance issues and > amusingly in this case, even in time sensitive code. > Same argument can be state about every application or test suite (LLVM sanitizers not tested in almost 1 year?), that we can rewrite everything which is futile process. > Joerg >
Attachment:
signature.asc
Description: OpenPGP digital signature