frequency_hot_code_reloading.md

1> % first compile frequency using contents of frequency2.erl
1> c(frequency).
{ok,frequency}
2> frequency:start().
true
3> frequency:allocate().
{ok,10}
4> frequency:allocate().
{ok,11}
5> frequency:allocate().
{ok,12}
6> frequency:allocate().
{ok,13}
7> frequency:allocate().
{ok,14}
8> frequency:allocate().
{ok,15}
9> frequency:allocate().
{error,no_frequency}
10> % replace with contents of frequency3.erl and recompile
10> c(frequency).
{ok,frequency}
11> % trigger code reloading
11> frequency:allocate().
{error,no_frequency}
12> % test code purge
12> code:soft_purge(frequency).
true
13> frequency:inject([16,17,18]).
injected
14> frequency:allocate().
{ok,16}
15> frequency:allocate().
{ok,17}
16> frequency:allocate().
{ok,18}
17> frequency:allocate().
{error,no_frequency}

Notes

• Without triggering code reloading using fully qualified function call(s) then directly call frequency:inject/1 will cause the the shell frozen. This is because the running process is still using old version of code and has no idea how to reply a new type of request.
• One can use erlang:check_process_code(whereis(frequency), frequency) to check whether the current running process is using old code or not.
• Triggering code reloading using code:purge/1 right after c(frequency) will cause any running frequency process terminated as a result of using old version of code.
• One can observe the same result by calling c(frequency) more than once. It's because compiling will automatically lead to loading. The first call to c(frequency) will load the new version of code and mark the running version as old; the second call will load the file again, mark the already loaded (however not running yet) version as old, and purge the running version (terminate running process(es)).