FAQ terminology harmonisation

[Chris Pressey]

On Wed, 2 Apr 2003 13:18:15 -0600
Rick Pettit <rpettit@REDACTED> wrote:

> On Wed, Apr 02, 2003 at 12:33:27PM -0600, Chris Pressey wrote:
> [...]
> > Because runtime linkage typically only happens once during a run of
> > a program, whereas hot code swapping can happen any number of times
> > with any number of changes the to code in the interim.
> 
> Well yes, unless the C/C++ application loading the shared object
> (which in turn requires runtime linkage) does so over and over again
> (i.e. loads .so, then later unloads and reloads NEW .so, and so on).
> In this case I don't see the difference.

But how often does this happen in practice?

My impression is that .so's are employed almost exclusively so that an
application doesn't use up memory for code until it knows it needs it.

i.e. for many (most? all?) programs that are built with .so's I've also
seen options to build them with statically linked-in libraries. 
(Sometimes this is done to make it easier for the user, so that they
don't have to download .so's and/or so the system won't accidentally try
to load old .so's.)

> Unless I am missing something here, regardless of type checking the
> interface to the [shared object|hot code being loaded] MUST remain the
> same in BOTH cases. Of course the code behind the interface can change
> as much as it wants to, also in both cases. In this sense I see no
> difference between Erlang hot code load and loading/unloading of
> shared objects.
> 
> Am I missing something?

Not really - it's not as much a question of capability, as it is of how
they're commonly used.

Perhaps the issue is that compiled programs using .so's generally aren't
fault-tolerant in the same way Erlang is, so using them for hot-swapping
is that much scarier.  At least with a well written Erlang program, if
you swap in something that's up to no good, you can swap it out again
and put in the old thing.  With a C program, the seg fault would have
already happened, and there would be nothing more you could do.

Either way, the interface can't change... well, yes and no.  The
interface between functions can't change.  But the interface within the
data passed to the functions might.  A new option {foo, bar} might be
added to a list of configuration options, or an old one might be
deprecated.  Not sure if this is what you were thinking of, though.

> -Rick

-Chris