Hotswap

[Peter-Henry Mander]

You reminded me I need to add the -export([server/0]) and a number of 
other things, oops!

And I think there lies the answer to your question: internally the 
module may change radically, but if you inconsiderately change the 
exported function signatures, you can expect the server to throw an 
exception, which hopefully the program writer will catch with another 
linked supervisor process, which may potentially diagnose the error and 
revert to a previous version. I'm speculating here, I haven't actually 
done this before, but the explanation on error handling and robust 
applications in the Concurrent Programming in Erlang book is quite easy 
to grasp. I highly recommend this (rare) book!

This doesn't prevent the new version from *enhancing* the exported 
interface, or adding new exported functions, which highlights another 
strength of Erlang as a prototyping tool. You could potentially write 
the code to enable the change from one module design to a totally 
different one, by proceeding in stages to switch the server loop from 
one tail recursive function to another in the new module.

I'm going to attempt a functioning example of switching code within a 
running server process in the next hour (work permitting) and hopefully 
follow this up on the mailing list. It's a good toy project and will 
solidify my understanding too.

Pete.


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?
> 
> If not, what about new functions that server() might call
> in the new version?
> 
> If so, why does Chris say that
> the interface must stay the same -- wouldn't loading
> the whole module introduce a potentially new interface?
> 
> jay
> 
> 
>