Re: PATCH libatomic

[Joerg Sonnenberger <joerg%bec.de@localhost>]

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.

> 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.

> 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.

Joerg