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