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@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals