gen_server communication conventions

Ulf Wiger ulf.wiger@REDACTED
Mon Jun 21 16:13:31 CEST 1999

You should use gen_server:call(Server, Request) on the client side,

and then, on the server side (an example):

handle_call(Req, From, State) ->
   Pid = spawn_worker(... Req),
   NewState = queue_request(From, Pid, State),
   {noreply, NewState};

handle_info({result, Pid, Result}, State) ->
   {From, NewState} = extract_request(Pid, State),
   gen_server:reply(From, Result),
   {noreply, NewState}.

I hope this was reasonably clear. 
The trick is that you return {noreply, NewState} instead of {reply,
Reply, NewState}, and then use gen_server:reply(From, Reply) at some
later stage.

Actually, in the next release of OTP (also in the current commercial
release), the gen_server client side monitors the server process (using
a one-way monitor function), and will EXIT immediately if the server
terminates. This is a big improvement over the previous implementation
(where you had to wait for a timeout).

With your solution, you'd bypass that functionality, and would have to
implement your own monitor or timeout watch.


Luke Gorrie wrote:
> Hi again all,
> I've got another question regarding gen_server.  This time, my server
> doesn't seem to quite fit the gen_server mould.  I want to make
> synchronous invocations from clients, but I'd like the server to be
> able to defer responding beyond the scope of the call resulting from
> gen_server:call().  This seems simple enough to implement: I have the
> client make a 'cast' to the server which includes the client pid; the
> client blocks on a receive for a response; the server later, based on
> some event or other, sends the response directly to the client
> process; the client returns with the result.
> My question is: Is that a "good" way, or can it and should it be
> managed instead through a standard behaviour somehow?  I can't really
> see how it could be mapped onto straight gen_server calls.  I'm not
> familiar with what magic goes on inside gen_server, and I just want to
> make sure I wouldn't be disabling some of the features associated with
> the gen_server behaviour by doing this.
> Thanks!
> Luke

Ulf Wiger, Chief Designer AXD 301      <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuvägen 9, Älvsjö                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44

More information about the erlang-questions mailing list