[erlang-questions] why does rpc:call do this?

[Cian Synnott]

Hi Garry,

On Wed, Jul 13, 2016 at 1:00 AM, Garry Hodgson <garry@REDACTED> 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
apply/3 call.

`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
the background.

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

Cian