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. amluto · 1789765627 · focus · HN ↗

      I grilled an LLM for a bit to see if it could justify the old forward progress rule. The only thing I got that passed the smell test was that it’s useful for the optimizer to be able to optimize:

          messy_pure_computation();
          some_atomic.store(1, relaxed);
      

      by moving the store before the computation. (Stronger stores would require additional analysis.)

      I admit I’m unconvinced that this is particularly useful.

      (I got many other ideas that did not pass my personal smell test.)

      1. mitxela · 1789777824 · focus · HN ↗

         I thought it was generally so the compiler can merge two computation loops without proving if one of them runs forever .

         1. murderfs · 1789782969 · focus · HN ↗

            Correct. See N1528: &quot;Why undefined behavior for infinite loops?&quot; <a href="https:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg14&#x2F;www&#x2F;docs&#x2F;n1528.htm" rel="nofollow">https:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg14&#x2F;www&#x2F;docs&#x2F;n1528.htm

            1. cryptonector · 1789832474 · focus · HN ↗

               That is not worth this nonsense.

Unofficial Hacker News client; not affiliated with Y Combinator.