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. yk · 1789756862 · focus · HN ↗

         I would expect an infinite loop

             while(true) std::this_thread::yield(); 
         

         to be designed to play nice with the scheduler, while I would assume a infinite loop

             while(true);
         

         to not play nice with the scheduler. Now, I can't really imagine where this matters except for horrible hacky attempts at faking a real time scheduler on windows, but breaking horrible hacky attempts at faking a real time scheduler sounds like the kind of bug you hear about in the evening news.

         1. nicebyte · 1789776832 · focus · HN ↗

            under what conditions would the infinite loop be scheduled over something else after it has run out of its time slice?
         2. rcxdude · 1789777655 · focus · HN ↗

            I would expect them to be the same or for the former to be worse. It's rarely useful to call sched_yield at all, but calling it repeatedly in a loop seems more likely to expose bad behavior in a scheduler than improve the interaction. Schedulers are already perfectly well designed to handle threads trying to take up 100% of the CPU: that's the default state for any CPU-bound task.

Unofficial Hacker News client; not affiliated with Y Combinator.