Distributed spawn-linking.

Alex Arnon alex.arnon@REDACTED
Tue Aug 9 10:04:21 CEST 2005


On 8/8/05, Per Hedeland <hedeland@REDACTED> wrote:
> Chandrashekhar Mullaparthi <chandrashekhar.mullaparthi@REDACTED>
> wrote:
> >
> >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...)
> 
> or
> 
> 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
> afterwards.
> 
> 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
> 

Thank you all for your answers. This answers my question :)
One last query - is this behaviour that I can rely on in the future
(as far as the documentation binds us)?



More information about the erlang-questions mailing list