Changing Code

[Matthias Lang]

Hi,

For what it's worth, our little SS7 box has a fair bit of Erlang in it and
we have never used hot code loading to upgrade live systems.

Richard Carlsson writes:

 > The dynamic code update semantics of Erlang is a nice feature when
 > you're in prototyping mode, but for production code, the fact that any

The difference between production and prototyping isn't always
clearcut. It may take a long time during testing to get a system to
behave strangely (e.g. performance degradation after a week of load
testing). It's nice to run that sort of testing on code intended for
production, but convenient to then load in instrumented code without
having to restart the system and wait another week for the problem to
show.

That goes double if the misbehaving system is in a customer's test lab.

 > 	- Is it necessary to be able to exchange any single module?
 > 	  (E.g., if your application consists of a number of modules,
 > 	   do you always replace all these modules anyway?)

Doesn't replacing all but one module in a system with the same code as
is currently running amount to the same behaviour from the user's
point of view? I guess it requires more confidence in your CVS setup
if those 'identical' files are recompiled.

 > 	- Could code migration be limited to specific functions, or
 > 	  is it necessary to be able to switch to a new version at all
 > 	  "remote" calls. (E.g., one could imagine a new declaration
 > 	  for specifying only certain functions as code update points.)

The most common code load for me is loading new code for a
gen_server. I usually don't care exactly when the switch happens, as
long as (a) it happens within a few seconds and (b) I know that it happened.

 > 	- Do you always use the OTP release handler or similar to
 > 	  do code updates, or do you do it by hand, or with your own
 > 	  in-house tools, etc? Do you find it simple as it is today,
 > 	  or is code update so difficult that you try to avoid it?

I do code update by hand.

 > 	- How much of a problem are circular module dependencies in
 > 	  practice?

Never bumped into this problem.

 > 	- Is the flexibility of being able to change any module at any
 > 	  time (even in production code) worth more to you than the
 > 	  speed of the code?

All the bottleneck code in our system is written in C, either as a
device driver or a port program, so for that code the "speed is more
important than hot code loading" decision has already been taken. In
most of the remaining Erlang code, I'd be loathe to give up hot code
loading.

If there was a compiler switch for "faster standard libraries but no
hot code loading for them", I'd enable it.

Matthias