[erlang-questions] Remote "access" points

Roberto Aloi roberto.aloi@REDACTED
Wed Nov 18 11:14:02 CET 2009

> Hello all,

> I am looking through the Erlang source for any remote access points.
> My plan is to try restricting what can be called on a node.
> I've found the ones for spawn - partly because I was looking in the
> right place, and partly because they're helpfully commented in
> net_kernel.erl as
> %%
> %% The spawn/4 BIF ends up here.
> %%
> handle_call({spawn,M,F,A,Gleader},{From,Tag},State) when is_pid(From)
> ->
>     do_spawn([no_link,{From,Tag},M,F,A,Gleader],[],State);
> By changing that to
> handle_call({spawn,M,F,A,Gleader},{From,Tag},State) when
> is_pid(From),
> M =:= 'public' ->
>     do_spawn([no_link,{From,Tag},M,F,A,Gleader],[],State);
> I get the desired effect. Trying to spawn('paranoid@REDACTED', os,
> cmd, ['ls']) fails on the calling node (although the "paranoid" node
> dies a noisy death which isn't ideal, but is fine for testing).
> Spawning a public:* function works.
> However, I'm not able to find the place where rpc:*call requests
> arrive. Can anyone point me at the right place? As well as any other
> points at which remote nodes can start new processes.

I'm not sure you're heading to the right direction. I mean, tweaking the core code, identifying all entry points...
What are you trying to do exactly?

> Another thing - putting a debug io:format doesn't seem to be a good
> way to debug which functions are being hit - is there a better way?
I would suggest you to have a look to the dbg documentation:


A simple tutorial from my blog:

> Someone also mentioned that when you obtained a Pid from a spawn, you
> can do other things with it? Could someone explain what you can do
> with it?
Try to have a look to the concurrent programming section from the erlang.org website:

Also, here's explained the structure of an Erlang Pid:


Roberto Aloi
Erlang Training and Consulting Ltd.

More information about the erlang-questions mailing list