[erlang-questions] Sending fun/1 over the network and apply/2 failure

[Joe Armstrong]

Erlang funs are not portable over network nodes. The reason being that
the underlying beam code that implements the funs is not guaranteed to
be the same on all participating nodes.

If you can ensure prior to evaluating the fun that the compiled module
code is available
on all machines then funs are portable (note you also must have the
same version of Erlang
running on all nodes).

The reason is largely historical. The first Erlang clusters ran on
nodes with a common
NFS mounted file store, so although the nodes ran on different
physical machines they accessed the same file store. In the usual mode
of operation files would be updated on one node then the entire
application restarted over several nodes and thus all nodes saw the
same version of the compiled code. If the odd process crashed due to
code incompatibilities it would be restarted  (think supervision
trees) and on restart pick up
the latest version of the code (so in practise this worked, though
it's not 100% theoretically sound - there are edges cases where this
would not work).

If you want to make this work you just have to make sure that all
nodes have the same
version of the module(s) concerned. I guess just should be in quotes
(ie "just") since
this is very difficult (having 2 different versions of code on one
node is just about
understandable) but doing this over multiple nodes is far more difficult.

The "send the same code to all machines - then restart" strategy is
just about the
easiest way to make this work.

Cheers

/Joe






On Mon, Jul 25, 2016 at 2:17 PM, Sid Muller <sid5@REDACTED> wrote:
>> Sent: Monday, July 25, 2016 at 6:49 AM
>> From: "Mikael Pettersson" <mikpelinux@REDACTED>
>> To: "Sid Muller" <sid5@REDACTED>
>> Cc: erlang-questions@REDACTED
>> Subject: Re: [erlang-questions] Sending fun/1 over the network and apply/2 failure
>
>> A closure only contains a reference to its code, not a copy of the code
>> itself.  Taking a closure created in module M, passing it to another
>> Erlang node and applying it there, requires that the module M is present
>> there as well.  If it isn't, or if the modules differ too much, you get
>> a badfun exception.
>>
>> The code part of a closure created in the shell refers to a module in
>> the Erlang interpreter (erl_eval or something like that) with the actual
>> expression being a plain term in the closed over free variables (which
>> the module can interpret).  That's why the shell's closures work in some
>> cases where closures from beam files don't.
>
> Ahhh, OK that makes sense.
>
> Thank you
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions