On Fri, 9 May 2025 at 07:54, Sergey Vojtovich via developers < developers@lists.mariadb.org> wrote:
Monty and I had an argument recently regarding pthread_yield() and std::this_thread::yield() usage.
My position is: pthread_yield() should be removed in favour of std::this_thread::yield(). Benefits:
Agree here.
1. Must be available to all current MariaDB versions. C++11 is a must since 2018.
per https://jira.mariadb.org/browse/MDEV-35837 we've declared our current standard on 11.8+ as C++17
2. Compatibility and portability, which we don't have to care about.
I do pity our FreeBSD/OpenBSD/Illumios/MacOS maintainers that frequently submit one or two changes every second release.
3. I have no performance concerns after analysing how it is implemented by clang and gcc. 4. Goes inline with "MDEV-35461 - Remove redundant checks for standard library functions" 5. Standard things looks more community-friendly, e.g. why should MSVC developers care about POSIX threads?
To attract new developers, both employment and contributions, we should use all stable features that exist in the compilers supported by the supported distros of our codebase. It seems the mariadb.com job adverts on Senior C++ Database Engine Developer have qualification "You use the C++20 standard since 2020 and C++17 since 2017.". How disappointed are they going to be in employment when C++20 is a no go and even C++17 construct usage is rare? Do you think staff will be retained up until when C++20 becomes allowed is to be possible? Insisting on code constructs that existed before many new developers are born is a sure way to put them off. Thinking back to my early career (also a a long time ago) I had no desire to work on COBOL or Fortran (even though I didn't and still don't know anything about them). To avoid a "I worked on those", this isn't a reflection of the technology, just I didn't, and still aren't, in tech to work on "old stuff". The Foundation goal of continuity and openness can only be met while people are willing and able to work in the codebase. 6. complexity Currently highlighted below, the variety of options is creating large complexity in the codebase. We should trust, but validate via testing that C++ implementers can implement these appropriately. They have great skills, and are typically employed by a distro or hardware platform company that has easy access to those hardware professionals to validate an exceptionally optimal implementation. As a highlight of an old PR of mine where we took a "we know better stance" and never re-revaluted in 18 years https://github.com/MariaDB/server/pull/698 (which got effect, but we retained the old code under a not accessible define, but still got effort better spent elsewhere put into it recently maintain to conform to compatible behaviour). As our current bug queue indicates that we've got enough to handle on the database layer of things without maintaining, dare I exaggerate slightly not-invented-here, low level constructs well maintained elsewhere.
Currently pthread_yield() can be defined to:
1. SwitchToThread() - Win32 (Wlad, 2009)
...