[erlang-questions] gen_server call and reply

[Matthias Lang]

 > ML> In the case of the long-running request, what I do instead is
 > ML> 
 > ML>   {reply, {pending, Ref}, State}
 > ML> 
 > ML> where Ref is a reference which is then included in a later message
 > ML> sent the old-fashioned way. This amounts to more or less the same as
 > ML> 'noreply', though it's one message more expensive and has the benefit
 > ML> of making it easier to reason about timeouts, at least to my mind.

Hakan Mattsson writes:
 > If the reply is really critical for the client (that is
 > it cannot do anything useful without the reply) it
 > would be simplest for the client to just wait
 > indefinitely for the reply.

It doesn't have to be a question of critical or not. 

A telecom example: you have a media gateway for conference calls. It
has a gen server F which accepts commands from the outside world and a
gen server G which talks to the switch hardware to set up the
call. The switch hardware has relatively high latency.

Simplest approach: F call()s G to set up the call. G replies when the
call is actually set up.

Cheating approach: F cast()s G to set up the call. Failure becomes 
harder to handle.

Third approach: F call()s G to set up the call. G commits resources
to the call and replies 'pending'. Then, G tells the switch to do things.

The third approach lets you achieve more calls per second than the
simplest approach. There are also other ways to achieve the same
thing.

 > Assuming that the client can do something useful while
 > waiting for the reply, it could make sense to use the
 > {pending, Ref} strategy. But would it not even be
 > simpler to use an explicit receive in the client,
 > instead of polling the server repeatedly for the
 > outcome of {pending, Ref} in that case?

Yes, that's more or less what I meant by "the old fashioned way".

Matthias