[erlang-questions] Thoughts on when to use 'infinity' timeouts for gen_server:call and friends

[Mazen Harake]

  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 
processes.

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 
interprocess communication.

Hope this makes sense :D

/Mazen

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
> everywhere?
>
> Thanks,
>
> Andrew
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>