4 ms·
How is that reasonable ? With an infinite timeout, you are liable to have dead connections pile up forever on any network event that causes the peer to go silen
by noselasd 8y ago
How is that reasonable ? With an infinite timeout, you are liable to have dead connections pile up forever on any network event that causes the peer to go silent
Or you have to handle timeouts at another level in your code, which is reasonable - but can make things a lot more complicated.
- klodolph 8y agoInfinite timeout is often (rather, almost always!) better for layers where the timeout should be higher in the stack. The timeout or cancellation happens at the topmost level and then propagates downwards. This is not any more complicated than a timeout, and it saves you an enormous amount of pain. For example, let's suppose a particular operation is timing out, and while you might want to fix underlying issues, for now you might to increase the timout. You can fix it by adjusting the timeout at the topmost level without worrying about other levels. If you use timeouts everywhere, you might have to adjust timeouts everywhere. So as a default, I would say, only put timeouts at the top. You can then evaluate putting timeouts elsewhere as necessary. I've also found it very helpful in certain to do things like stream results as they are generated, so you can set a deadline and use whatever partial results you get before the deadline. In particular this is very useful if you have flaky hardware, or very large queries (in terms of number of systems they touch).