On 07.05.2020 22:45, Joerg Sonnenberger wrote: > On Thu, May 07, 2020 at 10:13:30PM +0200, Kamil Rytarowski wrote: >> 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. > > So you haven't done the research on the arguments given last time. Just > to save you the trouble, the immediate arguments without spending lots > of mental time are: > > (1) They introduce non-trivial blocking conditions, often defeating the > reason for using atomics in first place. > (2) They don't work in a constrained environment and are broken by > common UNIX primitives like memory mapped IO or shared memory. > (3) They are not async signal safe. > libatomic is a workaround and delivers standard runtime feature that is defined in C and C++ (and rust, ziglang, go and others) and none of the above is a blocker in real software. None of the above corner cases is a real world issue. If we would care about them, we would forbid using many other standard features such as floating point numbers... just because in corner cases they are not reliable. >> Both are no issue in real life as otherwise NetBSD wouldn't be the >> (almost?) only leftover without libatomic. > > All the world is Linux x64 and most people don't care about anything > else. That's the core issue and not whether they are a bad design > decision for portable software. Even then, I never objected to providing > libatomic in pkgsrc and use it as low effort hackaround for broken > software. I am strongly against anything in base depending on it though > exactly because it is a lazy's person fix. > libatomic is mandatory for x86_64 linux as well, mostly for 16byte atomic operations (although this is available in recent x86_64 CPUs). libatomic (or equivalent feature) shall be a part the basesystem as the NetBSD system provides C runtime. >> Coincidentally futexes share the same arguments against multiprocess >> operation. > > Coincidentally, the reason that implementing futexes is non-trivial is > exactly because they target multiprocess operations. Try again, will > you? > >>>> 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. > > Ah right, you have taken a short cut and therefore happy with the > result. Proper design is a futile effort. > I'm fine to see a better libatomic design, but over the years (I see discussions for like 5 years in NetBSD), nothing happened. libatomic in llvm/gcc is what is good enough in real software on all non-constrained platforms. > Joerg >
Attachment:
signature.asc
Description: OpenPGP digital signature