Without being dogmatic about it, I feel similarly about fixing things by inserting sleeps.
Without being dogmatic about it, I feel similarly about fixing things by inserting sleeps. At a high level, you often see programmers sprinkle sleeps into their code to "fix" race conditions or deadlocks. That doesn't really fix the problem, it just moves it around and it's usually done because they don't know how to reason about the underlying problem and fix it properly. You need to sleep long enough that whatever you're waiting for will definitely have finished. Most of the time you have no exact guarantee of that, so you have to pick some N that is relatively large. Inevitably, no matter what N you pick, sooner or later, the thing you're waiting for will take N + 1 and things break. To make it worse, the N + 1 situation often happens because you're getting an unusually large amount of traffic or because something else in the system is already in a failure state. So the breakage tends to come at the worst possible time and exacerbate things. Meanwhile, if you sleep for N ms somewhere, one thing you can guarantee is that whatever you're doing will take at least N ms. There's no way to make it faster, even if it may have been unnecessary to wait that long. Often not a big deal, but the more developers sprinkle sleeps into their code, the more often you run into bizarre performance bottlenecks as a result. Network timeouts and similar are kind of a fact of life, so there's no perfect solution. But if you find yourself trying to solve a problem by sleeping for some arbitrary period of time, a little alarm should go off in your head telling you that there's probably a better solution.
Posted by thraxil on May 22, 2015, 8:22 AM
Tags
Related issues
- (1) Because it doesn't actually solve the problem.
- Every time fossil comes up, I hear this same issue - "why is there no rebase?" And honestly, I've never been able to get this argument.
- My biggest problem with running local LLMs on my M4 Max/128GB RAM is the prefill latency.
- Biggest problem with httpx I see is authors sanity https://github.com/encode/httpx/discussions/3784 .
- There aren't many situations today that make one think: Why doesn't this business have a website?
- > IAM can stay MS That's leaving the most critical component still with a US company.
Raise real-world problems, find people facing the same issue, and discuss solutions.6,500 issues0 comments
hackernews (Network)
(1) Because it doesn't actually solve the problem.
Every time fossil comes up, I hear this same issue - "why is there no rebase?" And honestly, I've never been able to get this argument.
My biggest problem with running local LLMs on my M4 Max/128GB RAM is the prefill latency.
Biggest problem with httpx I see is authors sanity https://github.com/encode/httpx/discussions/3784 .
There aren't many situations today that make one think: Why doesn't this business have a website?
> IAM can stay MS That's leaving the most critical component still with a US company.
I am very petty about this one bug and have a very old axe to grind that this reminded me of!
Not just the edge router.
Without being dogmatic about it, I feel similarly about fixing things by inserting sleeps.
Without being dogmatic about it, I feel similarly about fixing things by inserting sleeps. At a high level, you often see programmers sprinkle sleeps into their code to "fix" race conditions or deadlocks. That doesn't really fix the problem, it just moves it around and it's usually done because they don't know how to reason about the underlying problem and fix it properly. You need to sleep long enough that whatever you're waiting for will definitely have finished. Most of the time you have no exact guarantee of that, so you have to pick some N that is relatively large. Inevitably, no matter what N you pick, sooner or later, the thing you're waiting for will take N + 1 and things break. To make it worse, the N + 1 situation often happens because you're getting an unusually large amount of traffic or because something else in the system is already in a failure state. So the breakage tends to come at the worst possible time and exacerbate things. Meanwhile, if you sleep for N ms somewhere, one thing you can guarantee is that whatever you're doing will take at least N ms. There's no way to make it faster, even if it may have been unnecessary to wait that long. Often not a big deal, but the more developers sprinkle sleeps into their code, the more often you run into bizarre performance bottlenecks as a result. Network timeouts and similar are kind of a fact of life, so there's no perfect solution. But if you find yourself trying to solve a problem by sleeping for some arbitrary period of time, a little alarm should go off in your head telling you that there's probably a better solution.
Comments (0)
No comments yet. Start the discussion.