Mon Aug 12 14:35:44 CEST 2002
We have a lot of code on production systems (too many to count fast).
> - 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?)
> - 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.)
> - 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?
Pretty much all our changes are done by hand. Reasons being, sometimes the
complexity of the change and lack of time to understand the release handler
fully and use it correctly.
> - How much of a problem are circular module dependencies in
We haven't encountered this problem in our applications.
> - 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?
To put a lot of emphasis - YES! Speed has never been a problem for us - we
exceed the requirements put to us by a few orders of magnitude. This feature
> - 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.
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
More information about the erlang-questions