[erlang-questions] hot code reloading
Sun Mar 2 09:40:09 CET 2014
Thanks for the clarification.
I ran a simple test:
%% begin code
after 3000 ->
local_call() -> local_call.
remote_call() -> remote_call.
io:format("local_call: ~p~n", [local_call()]),
io:format("remote_call: ~p~n", [hot:remote_call()]),
%% end code
updating local_call/remote_call to
local_call_updated / remote_call_updated .
And you're absolute right, the hot:remote_call() line called the new function.
Thanks for the clarification!
On Sun, Mar 2, 2014 at 12:10 AM, Bob Ippolito <bob@REDACTED> wrote:
> The remote call bar:hello() will always call the newest version of
> bar:hello/0. The calling module is irrelevant, even if the call happens from
> the old version of bar the newest version will always be called using that
> syntax. A local call from bar to hello() (or an equivalent closure) would
> use the current version referenced by that process.
> Modules are not linked together in any way so how or when they were compiled
> is not so relevant.
> On Saturday, March 1, 2014, t x <txrev319@REDACTED> wrote:
>> I'm reading Chapter 8 of Programming Erlang, and I want to verify if
>> my mental model of erlang code reloading is correct. My erlang is a
>> bit weak, so I'm going to use C++ notation.
>> Is the above correct with respect to *compile* and *lookup* ?
>> It seems to me the defining characteristics of erlang's code hot
>> reloading is:
>> * we have an "old" and a "new"
>> * the new becomes the old, and we kill all processes spawned by the old
>> Suppose we have
>> * module foo, module bar;
>> * foo:hi(), refers to bar:hello();
>> * we recompile bar; now, all foo's references to bar, uses the
>> _latest_ bar, not the bar that existed when foo was compiled
>> If I have misunderstood anything, please correct me.
>> erlang-questions mailing list
More information about the erlang-questions