Hotswap

[Ulf Wiger]

On Wed, 2 Apr 2003, Jay Nelson wrote:

>Peter wrote:
> > -module(simple_server).
>
> > server() ->
> >     receive
> >        {tagA,Data} ->     %% do A ...
> >                server();      % <<<<<<<<<<<<<<<< case A
> >        {tagB,Data} ->      %% do B ...
> >                simple_server:server(); %<<< case B
> >      end.
>
>Does the entire module simple_server get loaded?

Yes.

>If not, what about new functions that server() might call
>in the new version?

server() might call other functions in the same module, and
as long as they are not fully qualified
(Module:Function(...)), it will be a "local" call in the
same version of the module.

If it's a fully qualified call, the function has to be part
of the module interface. This is still OK, if that function
acts only on the provided arguments (is side-effect free)
and it's semantics haven't changed in the upgrade.


>If so, why does Chris say that the interface must stay the
>same -- wouldn't loading the whole module introduce a
>potentially new interface?

The interface needs to be backward compatible in the areas
that matter (the functions that can be called by old code
during or after the upgrade). A way around this is to rely
on the OTP code change mechanisms, which allow you to
specify dependencies between processes and modules; this
way, you can suspend processes that might call incompatible
functions or otherwise mess up the upgrade. OTP allows you
to perform a fully synchronized, orderly upgrade of a
complex, multi-node system -- provided you can figure out
how from the documentation, which is no small feat.  (:

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes