On Sat, May 9, 2020 at 10:39 Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 2020-05-09 17:18, connor horman via Std-Proposals wrote:
> >
> >
> > On Sat, May 9, 2020 at 10:14 Andrey Semashev via Std-Proposals
> > <std-proposals_at_[hidden] <mailto: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.
>
> I don't think using pure C/C++ for kernel (or bare metal embedded)
> development is practical. Primarily because these languages require
> certain runtime support and don't implement certain low-level
> primitives, like halting the CPU or switching the current execution
> context or setting up MMU for memory paging and memory mapped IO or many
> other hardware-specific things. That includes setting up hardware
> interrupt handlers. These primitives are normally written in assembler.

I do agree (my interrupts are set by a linker script because they have to
be a specific address which overlaps a text segment. However, things like
looping forever are a high-level concept that should shouldn't need
assembly for.
My rule is once I leave assembly, I don't return except for low level
concepts (like writing to an msr) or I need to do something incredibly arch
specific. I can't consider that an infinite loop is either too low level
for C++, or that it requires arch specific behaviour.
An infinite loop is actually a behaviour of a UTM. For the most part, it
seems like C++ has gone and solved the halting problem by saying "x does
halt" (in this case, halting means returning or exiting).

>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>