[erlang-questions] why does rpc:call do this?
Wed Jul 13 02:47:57 CEST 2016
On Wed, Jul 13, 2016 at 1:00 AM, Garry Hodgson <> wrote:
> which spawns a process to run the function, stash its results in S, and send
> results as an erlang message to rpc process.
The trick is that it is not the *result* that's stashed in `S` (the
RPC gen_server's state), but a mapping of `Caller` : `To`.
`Caller` here is the pid of the spawned process which does the actual
`To` is the RPC client that initiated all this.
As the comment notes, the apply/3 is done in a separate process so
that the RPC gen_server itself can get on with handling its next
message while some set of potentially long-running apply's happen in
When the apply/3 is done, `Caller` sends back a message that's caught
by handle_info as you note. The gen_server looks up the `Caller` :
`To` mapping from earlier, to discover what client should receive the
results sent back by the pid `Caller`.
The monitor is setup so that the RPC gen_server can clean up its state
if an apply/3 subprocess dies without sending back a message;
presumably another clause of that same handle_info deals with that
More information about the erlang-questions