[erlang-questions] what does l/1 really do?

Siri Hansen erlangsiri@REDACTED
Tue Aug 9 11:48:46 CEST 2011

Hi Daniel!

I also have a more specific question. I have a whole bunch of gen_fsm
> processes that I *believe* have a common supervisor but I won't swear to it.
> If I want to upgrade the module, is there a way to institute the code change
> right away across all those processes?
Most of this has already been said in this thread, I'm just adding some

If you do l/1 in the shell, the new version of your modules will be loaded
and taken into use the next time a fully qualified call is made to this
module. If your module implements an OTP behaviour, this will happen e.g.
the next time a message is passed to the process.

If the new version of the module includes e.g. a change of the state record,
the process might crash (if you try to match the state passed from the
behaviour against your new data structure). To avoid this, you must either
make your module totally backwards compatible, or implement a code_change
function and make sure this is called... preferably by using the
release_handler and an appup script.

If you have changed the interface of the module in a non-backwards
compatible way, you must make sure that all other modules using this
interface are also updated. Such dependencies can also be specified in an
appup script.

So, what does the release_handler do??

First, all appup scripts must be converted to one single relup script -
systools:make_relup. When generating a relup, systools will first generate a
directed graph of all the dependencies from the appup instructions. Based on
this graph, the depending modules will be grouped together, and e.g. an
update instruction for a module will be converted to a {suspend,DepMods} -
load - code_change - {resume,DepMods} sequence in the relup.

During upgrade, the release_handler will traverse the complete supervision
tree and look at the module list in the child specs in order to find all
processes that have any of the DepMods as their callback. Load and
code_change instructions are then executed (both for the module in the
original upgrade instruction, and for the modules it depends on, if such
instructions exist). Finally, all processes are resumed.

So, to answer the question - l/1 will do the job, but only for the simplest
case where your update is totally backwards compatible and there are no
dependencies towards other modules.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110809/5e718da7/attachment.htm>

More information about the erlang-questions mailing list