[erlang-questions] Thoughts on when to use 'infinity' timeouts for gen_server:call and friends
Sun Aug 1 10:14:43 CEST 2010
A timeout is an assertion. If you allow timeouts then you should
prepare to handle them, if you don't then put infinity. Raising the
timeout is not logical because you can not be sure if it is enough...
My rule of thumb is:
Don't have cascading timeouts; push the "timeout" boundary as far out to
the edge as possible. If it times out there then you are safe because
you will crash all the way back and you can then handle that. It is far
harder to handle timeouts in the "middle" in a chain of calls between
E.g, consider this:
P1 -> P2 -> P3 -> P4
The only place where you should put a timeout (if you need one) is
between P3 and P4 [in general] and you should [in general] avoid putting
timeouts between P1, P2 and P3 (unless TimeoutProcesss1 > TP2 > TP3,
which pretty much defeats the purpose of timeouts anyway).
I think [but am not sure] that this is the reason otp does it; because
they don't want random timeouts occuring everywhere in between all the
Hope this makes sense :D
On 01/08/2010 09:43, Andrew Thompson wrote:
> So, in trying to scale my application, I run into some cases where the
> default 5 second timeout imposed on all gen_*:call behaviours isn't
> enough and I get cascading timeout failures. I've noticed that most of
> the applications in the OTP distribution use 'infinity' as the timeout
> for all their :calls().
> Basically my question is: does anyone have any good rules of thumb for
> when its OK to use a non-standard timeout? Most of my timeouts are
> coming from an external source (waiting on another program to do
> something). Should I just bulletproof certain core modules and say
> "these won't infinite loop, so they can take as long as they need"?
> Should I just do like OTP does and just stick 'infinity' in most
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
More information about the erlang-questions