Distributed spawn-linking.

Per Hedeland <>
Mon Aug 8 21:36:49 CEST 2005

Chandrashekhar Mullaparthi <>
>On 8 Aug 2005, at 17:37, Javier París Fernández wrote:
>> Hi,
>> On Mon, Aug 08, 2005 at 07:14:15PM +0300, Alex Arnon wrote:
>>> Thank you, but this does not answer my question, which is specifically
>>> about the behaviour of spawn(). I shall reword:
>>> - Is spawn(Node, ...) a synchronous operation? I.e. does the spawning
>>> process wait for the target node to acknowledge and assign the PID
>>> before returning?
>>> - If not, does Erlang handle the original example? And if it does, 
>>> how?
>> Well, as the spawn call returns the pid of the created process, it has
>> to be syncrhonous.

[ snip ]

>And if you look in kernel/src/erlang.erl you'll see exactly how a spawn 
>on a remote node is implemented. In short, you can't rely on the output 
>of spawn/4 or spawn_link/4 to "guarantee" that a process has been 
>spawned on the remote node. You'll need some application level protocol 
>to establish this.

But that wasn't the question either. If "doesn't exist yet" and
"synchronous operation" plus elaboration isn't clear enough, maybe this
rephrasing of (my understanding of) the question helps: Assuming that a
process actually *is* spawned on the remote node, can you be sure that
spawn/4 doesn't return its pid before the process really exists? And the
answer is "yes", which can be verified via your pointer to the source
(including following the gen_server call to net_kernel).

Possible reasons for a "no" answer could be:

There exists an optimization to assign/create the pid on the local node
before actually doing the remote spawn. (Of course this would require
some pretty complex implementation to allow all nodes to create unique
pids on behalf of all other nodes, so it probably wouldn't be an
optimization after all - plus it would be a pretty useless optimization
if it were one, since you don't have much use for the pid until the
process exists - if you're in a real hurry, you could always spawn a
local process to do the remote spawn...)


The pid is assigned/created by the remote node, but for some unknown
reason it doesn't do it via a normal local spawn, instead using some
undocumented/internal mechanism that delivers a pid first (which is sent
back to the originating node immediately) and does the actual spawn

Well, it *could* be implemented like that...:-)

Either way, and beside (my understanding of) the question, both the
"useless pid" returned on some errors, and the case of the process dying
before it is sent a message, will result in an EXIT signal due to the
link/1 being done by the communicating process (though of course the
delivery of that EXIT signal is *not* necessarily synchronous).

--Per Hedeland

More information about the erlang-questions mailing list