Subject: Re: [std-proposals] Remove infinite loop UB
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2020-05-09 09:53:10
On Sat, May 9, 2020 at 10:18 AM connor horman via Std-Proposals <
> 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
- 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`)
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.
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups