[erlang-questions] hot code reloading
Sun Mar 2 12:28:25 CET 2014
This is #$%-ing brilliant!
At first, I thought:
"this is a stupid way to demonstrate global-loop vs local-loop"
However, this does much more than that.
It means that
* when an existing loop is running
* after we do a hot reload
* after the code processes an old message
* it then calls the _new_ loop
Yeah, preaching to the choir, but this is awesome, and I have no one
else to share this intellectual excitement with. :-)
On Sun, Mar 2, 2014 at 1:31 AM, Gianfranco Alongi
> I actually recommend the documentation, it covers this in a few paragraphs
> On Sun, Mar 2, 2014 at 9:10 AM, Bob Ippolito <> 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 <> 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
>> erlang-questions mailing list
More information about the erlang-questions