<i>"It is possible to find the set of processes that refer to the old version of a module, so that they can be forced to terminate before purging the old code"</i><br>Does the system automatically terminate processes using the old version if that old version is removed? Or does it have to be done 'manually' by the programmer?<br>
<br><div class="gmail_quote">2008/12/12 Richard Carlsson <span dir="ltr"><<a href="mailto:richardc@it.uu.se">richardc@it.uu.se</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Austin Anderson wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm wanting to get into researching hot code swapping and was wondering if there was a (formal) semantics for Erlang's behaviour with respects to hot code swapping. I have read the Erlang 4.7.3 Reference Manual which I found through the website, which gives a semi-formal specification, but if there exists either in Erlang or in one of its spin off statically typed versions a formal specification as to how the system behaves with respects to hot code swapping I would appreciate being pointed in its direction.<br>

</blockquote>
<br></div>
No, I don't think anyone has written such a document. E.g., Lars-Åke<br>
Fredlund did not include the module system in the semantics in his<br>
thesis ("A Framework for Reasoning about Erlang Code", 2001).<br>
<br>
However, the rules are actually rather simple, and it should be<br>
straighforward for someone who knows his formal semantics to model<br>
the hot code swapping in a convincing way, given the informal<br>
specification you have already read.<br>
<br>
Basically:<br>
<br>
  - A module has a name, some attributes (a map from atoms to terms),<br>
    and some exported functions (a map from atom+arity pairs to funs);<br>
    see also the Core Erlang specification for comparison.<br>
<br>
  - There can be at most two loaded versions of a module: the current<br>
    and the old version.<br>
<br>
  - A remote call M:F(...), or a call to one of the variants of the<br>
    apply and spawn BIFs, always uses the current module to map the<br>
    module name to the actual function to be called. (In practice,<br>
    the linker does most of the job at load time, so there is no<br>
    lookup overhead at run time for M:F(...) calls.)<br>
<br>
  - It is possible to find the set of processes that refer to the<br>
    old version of a module, so that they can be forced to terminate<br>
    before purging the old code (in preparation for loading yet another<br>
    version).<br><font color="#888888">
<br>
  /Richard<br>
</font></blockquote></div><br>