Hi Daniel!<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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?<br>

<br></blockquote><div><br></div><div>Most of this has already been said in this thread, I'm just adding some details...</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>So, what does the release_handler do??</div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>Regards</div><div>/siri</div></div>