On Sat, May 9, 2020 at 10:18 AM connor horman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sat, May 9, 2020 at 10:14 Andrey Semashev via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> 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