4 ms·

It will not, even adding just a 1ms sleep in a loop will drop CPU usage to barely noticeable levels, 10 wakes a second is barely anything for any CPU from the p

• thwarted 2y ago
  This is what the pause(2) syscall was made for, waiting for a signal forever.
• Too 2y ago
  It’s a good way to drain your battery on mobile devices, even if usage looks low. Not that this matters for this particular tool.
  • erickj 2y ago
    > Not that this matters for this particular tool. Then the code is perfectly appropriate.
    • quotemstr 2y ago
      It's a bad example for others and a bad habit to get into. If every program did this, we'd have trouble getting CPUs into deep idle states.
      • enriquto 2y ago
        It's an irrelevant implementation detail. This is for a live call. You are streaming video at the same time, so there's no point in worrying about idling. I'd even say that it's a good example for others, because the equivalent code with the event loop would be slightly more complicated (maybe 5 more lines?). Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
        • asveikau 2y ago
          My guess is that somebody coded that event-loop-less X client not really familiar with the language and how to write Xlib apps. I partially assume this because C, C++ and especially Xlib are becoming less popular over time, so finding skilled practitioners to write it idiomatically is relatively rare now. This basic event loop stuff is something that maybe belongs in a library. So they just wrote library grade functionality themselves, badly. The commentary here is getting defensive about doing things the wrong way, coming up with lots of post hoc justification.
        • drdaeman 2y ago
          > You are streaming video at the same time, so there's no point in worrying about idling. I'd argue it's completely opposite of this. You're streaming video, already putting some significant stress on the system. No reason to waste time (even if it's a minuscule amount) to make things worse. > Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example. And that's how we ended with e.g. modern IoT that kinda sorta works but accumulation of minor bad decisions (and some less minor bad decisions for sure) ends up making the whole thing a hot mess.
          • account42 2y ago
            Sleeping for 100ms between checking for events will not produce a noticeable CPU load. The only reason this would drain the battery is because it can prevent the CPU from entering deeper powersaving states - but even for that 100ms is an eternity and video streaming will prevent that anyway.
        • qqj 2y ago
          [dead]
• funcDropShadow 2y ago
  Whether the CPU is busy because of a loop with a sleep depends on the ration of the sleep time and the time to perform the rest of one loop iteration. Doing stuff in a loop iteration that takes 1min and then adding a ms sleep will not drop CPU usage a measurable amount.
  • account42 2y ago
    The question is about waiting, i.e. when you have no real work to do. If you have significant work to do then there is no point in sleeping until that work is done.
• larschdk 2y ago
  Sure, if that is the only program, but it is not. This kind of thinking drains batteries faster than necessary, drains the cache, and reduces CPU efficiency. sleep() is a wasteful system call, a kludge at best, and is never the correct solution to a synchronization problem.
• asveikau 2y ago
  Not my experience at all. Granted I haven't tried writing a loop like this in 20ish years, because once you spot that mistake you don't tend to make it again, and CPUs are better now. Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.
  • diath 2y ago
    > Not my experience at all. Granted I haven't tried writing a loop like this in 20ish years, because once you spot that mistake you don't tend to make it again, and CPUs are better now. You can trivially verify it by running the following, I have personally been using "sleep for 1ms in a loop to prevent CPU burn" for years and never noticed it having any impact, it's not until I go into microseconds when I can start noticing my CPU doing more busy work. // g++ -std=c++20 -osleep sleep.cpp #include <thread> #include <chrono> int main(int, char **) { while (true) { std::this_thread::sleep_for(std::chrono::milliseconds {1}); } return 0; } > Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop. On what system? AFAIK, if your sleep time is low enough, it will round up to whatever is the OS clock resolution multiple, not skip the sleep call completely. On Linux, it will use nanosleep(2) and I cannot see any mention of the sleep not suspending the thread at all with low values.
    • asveikau 2y ago
      If memory serves, Windows treats a sleep under the scheduler quantum length as a yield. It may take you off the cpu if there's something else to run but it may not. Meanwhile burning up cycles may prevent low power states. At any rate, back to the code at hand, there are many ways to block on SIGINT without polling. But it's also hugely odd that this code does not read events from the X11 socket while it does so. This is code smell, and a poorly behaved X client.
      • orbisvicis 2y ago
        I thought that Linux behaved the same, but I'm not finding any proof in `man 2 nanosleep`...