There is sigwait for this kind of use cases. Or any other kind of
blocking - sleep, select, condition_variable::wait, etc.
Busy waiting as a means of blocking the thread for extended periods of
time is not something that should be encouraged, IMHO.
Ah yes, that works quite well in embedded/freestanding (or os dev, especially) where I don't have:
a) posix
b) <thread>
c) <mutex>
d) Stuff along those lines.
Well, that's the thing, right? All of what you just named are libraries, which are just collections of useful functions. You may not have access to those specific libraries, but you are certainly using a programming language (C++) that permits you to create functions of your own and place them into libraries.
Rather than open-code an "infinite loop" (which would violate the compiler's assumption that all loops eventually terminate), it would be better for you to create a named function with the semantics you really intend:
- spin the current thread forever without yielding
- repeatedly yield and reschedule the current thread forever
- deschedule the current thread so that it never gets scheduled again
- deschedule the current thread until a signal is received (`sigwait`)
etc.
You have the tools to create a function with any of those semantics, for your platform of choice, and then you can call it from C++.
The consensus in this (email ;)) thread seems to be that you should aim for the third or fourth semantics: busy-waiting is never a good idea, so you should look for a way to deschedule the current thread or task entirely.
–Arthur