Hotswap

[Peter-Henry Mander]

Okay, here's my example:

I do the following in the shell:

   8> c(counter).
   {ok,counter}
   9> counter:start(100).
   {ok,100}
   10> counter:test().
   incr
   decr
   decr
   decr
   reset (previous value=98)
   get_value => 10
   ok

All is well. Without issuing counter:stop() I modify the code by 
uncommenting the new code and commenting out the old. I recompile and 
run counter:test again:

   11> c(counter).
   {ok,counter}
   12> counter:test().
   incr
   **** switching NOW! ****
   decr
   decr
   decr
   reset (previous value=8)
   get_value => {10,new_parameter}
   ok
   13> counter:stop().
   10

Et voila! I've modified the loop by litterally switching from one tail 
recursive function to another (and modified the API for the sake of the 
demo) with very little effort and without stopping anything.

Stuff that into your C/C++ pipe and smoke it! (-:

Pete.

P.s. I'm an experienced C++ programmer, and I've _never_ found it as 
easy as *this* to hot swap code, neither as quick to implement! Yay Erlang!



Peter-Henry Mander wrote:
> 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
>>
>>
>>
> 
> 
> 
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: counter.erl
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030403/b10e0e6b/attachment.ksh>