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