One concern could be that dropping our sched_yield wrappers, or worsening its maintenance would affect the C part of the server, but I just checked that there is a C11 function as well: https://en.cppreference.com/w/c/thread/thrd_yield I remember, though, that some systems don't supply threads.h, or supply a picky set out of it. C++ is much more defined on what it provides. I think, C++-wide, we could stick to std::this_thread::yield. Modern toolset looks more attractive for a wide range of developers. There is still C, where pthread_yield would still be the way. Though, is doesn't address the "why windows developers should care about pthread" concern. So, for C, i'd suggest to transform my_pthread.h into C11 compatibility layer provider: 1. create a threads.h file 2. if HAS_THREADS_H is defined, it should #include_next it. 3. rename pthread_yield macro into thrd_yield and move it to our threads.h 4. include threads.h in my_pthread.h 5. our threads.h may be expanded with other stuff Alternatively, we can just use thrd_yield name everywhere, which is another new standard way in the C world! Though i guess much less known, than std::this_thread::yield. Regards, Nikita On Fri, 9 May 2025 at 08:43, Sergei Golubchik via developers < developers@lists.mariadb.org> wrote:
Hi, Daniel,
On May 09, Daniel Black via developers wrote:
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.".
This is a ColumnStore position, ColumnStore is much more bleeding edge.
Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin