Thread

1. JoshTriplett · 1789746575 · focus · HN ↗

   > When both conditions are met, the loop body is replaced with a call to std::this_thread::yield().

   Insert screaming here.

   An infinite loop, with no library calls whatsoever, gets a system call inserted. That's a horrible surprise waiting to happen.

   The entire concept of the "forward progress guarantee" is broken. An infinite loop should compile to an infinite loop. Nothing more, nothing less.

   1. ameliaquining · 1789747543 · focus · HN ↗

      I'm curious, what exactly do you imagine going wrong here?

      1. rcxdude · 1789747691 · focus · HN ↗

         The biggest headache will probably be it getting emitted in inappropriate contexts: where there is no actual means to sched_yield for whatever reason (bare metal, kernel, whatever). The second is just that the behaviour of the infinite loop changes: suddenly you're getting a bunch of extra system calls from your spinning thread instead of just a high CPU usage, which could disguise the issue or perhaps cause problems for other parts of the system. I don't see a good reason for the transformation: pretty much any time you are writing a bare infinite loop like this you don't want anything else to happen (it's also silly that it only happens with a particular spelling of an infinite loop, keeping the others still undefined).

         1. mitxela · 1789778033 · focus · HN ↗

            Impl specific. If you're building bare metal, pass -ffreestanding so GCC knows it's not allowed to call OS functions.

Unofficial Hacker News client; not affiliated with Y Combinator.