| Author |
Message |
|
| luke at javagroup.org |
 Posted: Mon Jun 21, 1999 1:50 pm |
 |
|
|
Guest
|
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
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ulf.wiger at etx.ericsson |
| Posted: Mon Jun 21, 1999 2:14 pm |
|
|
|
Guest
|
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.
/Uffe
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_at_etx.ericsson.se>
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuv |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
