Literally removing the sleep(10);

Nah jokes aside, reworking my entire code from scratch based on what I drew up on a board.

Sometimes visualisation of processes and control flow can really help you write better code.

99% of the time I see a std::thread::sleep or equivalent, I die a little inside.

Because they are done by inexperienced devs who do not understand the concept of happens-before ordering and proper blocking/polling.

My OS teacher would automatically limit your grade to a 5/10 if you used semi-busy waiting (eg, sleep in a loop), and automatically fail you if you ever busy waited.

Oh, and before anybody shits on me or my teacher, I'm perfectly aware that there are legitimate use cases for busy waiting, but those are very very specific and should not be allowed as default, especially while learning.

@CoreFusionX agree 100%

@CoreFusionX only legitimate thing I'd know is in things like device management, where for example the device spec explicitly says: wait 500 ms after doing X.

Out of curiosity: any other cases you can imagine?

Usually I told my interns:
Busy waiting: if you think you need it, you should fix your thinking.

*hehehehe*

I only used sleep once in my life in production. And it was some objective-c code with multiple threads.
Even though I was pretty sure it was the only way to achieve what I wanted, I still feel dirty when I think about it.

@IntrusionCM

It's often used in many lock-free implementations.

Depending on contention level, it can actually be faster to just busy wait some milliseconds than deal with the cost of many context switches in order to dequeue other tasks.

Sleep can also be used as a yield in platform/language combos that don't offer yield keyword or thread preemption.

But again, these are very very specific cases that 99% of the times anyone, me included, will get wrong.

C# also does it in synchronization contexts, to deal with async/await (kind of like node with the microtask/task queue differentiation).

But long ago since I dealt with it so details are a bit foggy, sorry.

Adding a sleep(1) to fast processes.

We literally had users spamming because "something wasn't doing anything"

@pmso it‘s better to add some feedback animation to the UI instead of sleep.