Changing Code

[Thomas Lindgren]

Richard Carlsson wrote:
>	- 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?)

Installing simple patches by loading new modules in a live system has been
used at both Bluetail and Cellpoint. (This can also be used to impress
customers :-)

>	- 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.)

Don't know.

>	- 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?

Bluetail used release handlers IIRC, Cellpoint does not.

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

I believe OTP is full of circular module dependences. (Since Erlang handles
this without complaint, most people probably don't, however, consider it a
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?

Yes.

>	- When you make a (remote) call that is expected to switch
>	  to new code whenever it has been loaded, could you guarantee
>	  that the call stack is empty at that point, i.e., you will
>	  not return to the old code, nor to the code that called it?
>	  (If so, the code purging stage would not have to scan the
>	  stacks of processes to find out if they must be killed.)
>	  This pretty much equals saying that code change always starts
>	  a fresh process, but keeps the old Pid.

No.

Best,
					Thomas