Date: Sat, 9 May 2020 04:01:44 +0200
Am Sa., 9. Mai 2020 um 03:03 Uhr schrieb connor horman via
Std-Proposals <std-proposals_at_[hidden]>:
>
> Currently in the C++ language, it is undefined behaviour to have an infinite loop without observable side effects. While this is nice on paper, it has a few issues. Any time you need to loop forever, you basically need to insert a (potentially costly) side effect. This applies any time you need are, say, running a game on a old console, and just need to spin while waiting for interrupts to do stuff (same with an os kernel). This results in requiring assembly to so this, or maybe insert an instruction to wait for an interrupt in a loop (both llvm and gcc allow the volatile specifier in an assembly declaration, which is treated as observable, so x86_64 code could use hlt (in CPL=0), 65816 could WAI). This, however, seems to violate one of C++'s core principles, that there is no lower level language.
What's wrong with waiting for a condition variable instead of spinning
and notifying that cv in the interrupt handler? That seems like a way
better alternative, as you don't waste resources (e.g. battery power
on a mobile console, but also CPU time).
> A further case would be an init process on linux, which cannot terminate (doing so results in a kernel panic), nor can just call hlt in a loop, as that's one way to get a #GP which probably translates to SIGILL. Once an init process is done setting up, it could want to just spin forever, and do so using as little system resources as possible. The logical idea would be just for(;;) std::this_thread::yield();, but that would be UB as yield() is not observable (correct me if I'm wrong).
I have never written an init process so I don't know the constraints,
but I'd hope no init process ever does that. I would not want a
process that has nothing left to do get assigned a time slice by the
scheduler only to waste it doing nothing. I imagine once the init
process is done it could just call sigwait and wait for the signal to
be terminated.
>
> Having the ability to spin forever, without wasting time actually doing stuff, seems like a reasonable thing to have in low-level code, so its very curious (and in many cases, annoying) that you cannot actually do this in real code that might have to.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Std-Proposals <std-proposals_at_[hidden]>:
>
> Currently in the C++ language, it is undefined behaviour to have an infinite loop without observable side effects. While this is nice on paper, it has a few issues. Any time you need to loop forever, you basically need to insert a (potentially costly) side effect. This applies any time you need are, say, running a game on a old console, and just need to spin while waiting for interrupts to do stuff (same with an os kernel). This results in requiring assembly to so this, or maybe insert an instruction to wait for an interrupt in a loop (both llvm and gcc allow the volatile specifier in an assembly declaration, which is treated as observable, so x86_64 code could use hlt (in CPL=0), 65816 could WAI). This, however, seems to violate one of C++'s core principles, that there is no lower level language.
What's wrong with waiting for a condition variable instead of spinning
and notifying that cv in the interrupt handler? That seems like a way
better alternative, as you don't waste resources (e.g. battery power
on a mobile console, but also CPU time).
> A further case would be an init process on linux, which cannot terminate (doing so results in a kernel panic), nor can just call hlt in a loop, as that's one way to get a #GP which probably translates to SIGILL. Once an init process is done setting up, it could want to just spin forever, and do so using as little system resources as possible. The logical idea would be just for(;;) std::this_thread::yield();, but that would be UB as yield() is not observable (correct me if I'm wrong).
I have never written an init process so I don't know the constraints,
but I'd hope no init process ever does that. I would not want a
process that has nothing left to do get assigned a time slice by the
scheduler only to waste it doing nothing. I imagine once the init
process is done it could just call sigwait and wait for the signal to
be terminated.
>
> Having the ability to spin forever, without wasting time actually doing stuff, seems like a reasonable thing to have in low-level code, so its very curious (and in many cases, annoying) that you cannot actually do this in real code that might have to.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2020-05-08 21:04:57