On 08.05.2020 14:44, Martin Husemann wrote: > On Fri, May 08, 2020 at 02:26:45PM +0200, Kamil Rytarowski wrote: >> With _Atomic() we can mark any arbitrary struct to have serialized >> accesses. As I said, with your attitude we shall remove FPU support (and >> softfloat) as they are not async safe, not safe in virtualization for >> MMU accesses and more just to mention 2 issues. > > Now come on, that certainly is apples and oranges. > They are relatively comparable. Softfloat is like libatomic with similar constraints. Softfloat shares similar problems to libatomic (like being so slow that the purpose might be gone). Standard C calls like setjmp(3) or longjmp(3) can mess the state of FPU, standard C signal handlers can mess non-lock-free atomics. We can redesign algorithms and avoid using atomics same as we can avoid using floats. > Joerg already agreed to have a "working" libatomic in pkgsrc, so all the > lazy programmers can use them and 3rd party apps will be happy. > > Why do you insist on importing it in base? > libatomic is an integral part of the toolchain and shall match GCC and Clang from base. There is ABI dependency, although the runtime library does not change often, we are supposed to keep a few years of support of a NetBSD host (and its toolchain). The library is implemented as a thin library in GCC and LLVM. We provide C11 (/usr/bin/c11) in basesystem. If we ignore C11 base, then we promise to deliver C++11. Atomics support is not a feature for lazy programmers, it is rather the opposite. Designing lock-free algorithms (with a fallback to locking ones in libatomic) is extra mental work. I generally agree that they can be misused, but the same argument can be applied to many other standard features. I also agree that there are corner cases when they fail, but again the same applies to other C features. I also agree that when we use libatomic (same as softfloat) the purpose o this feature might be gone in a performance critical software. Promptly designed software can detect atomic features in either compile tiem or runtime and act accordingly (abort, warn, permit, fallback to different algorithm). In many cases libatomics usage is good enough (same as softfloat). I object to opinions that libatomic is generally broken, if that would be the cause, it wouldn't be available and used on relatively all relevant generic purpose Operating Systems. Personally, I already received last year a feedback from one 3rd party project from Microsoft that they prefer to drop NetBSD support (out of Windows, Linux, MacOS, BSDs) rather than allow non-libatomic usage. If we allow libatomic in pkgsrc only, then we need to deliver possibly 2 versions (gcc and llvm) and/or bootstrap dedicated toolchain just for the purpose of building some software. This is too much burden compared to ~2k lines of .C + .H code from GCC... just because someone can misuse some legitimate feature. My point is that we shall not decide for users whether something could be misused. If someone wants to shoot into his or her foot, we shall not block it. I consider these concerns as exaggerated as libatomic is generally safe and simple to use. > Martin >
Attachment:
signature.asc
Description: OpenPGP digital signature