FAQ terminology harmonisation

[Rick Pettit]

On Wed, Apr 02, 2003 at 02:27:34PM -0600, Chris Pressey wrote:
> > 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?

Perhaps not often in other companies, but I have personnally written shared
object libraries that are meant to be loaded/unloaded/reloaded as the 
implementation behind the interface evolves.  Works really well, too, in that
C/C++ clients talk to Erlang servers via these shared objects, and as long as
the API from C/C++ app to shared object stays the same all sorts of neat
changes can take place both on server side (hot code load) and on client 
side (shared library swap), with NO DOWNTIME!

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

This is perhaps most common use.

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

Agreed.  I think that is the case.  Also, applications with statically compiled
shared objects do not need to make libdl calls to load/unload explicitly, IIRC.
Of course this means such binaries can NOT reload shared objects on the fly.

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

Agreed, though segfaults normally occur in software that is not defensive
and has not been coded under a test-first methodology.  Not sure there is a 
big difference between loading a shared object that core's the application
and hot-loading Erlang code that keeps killing the process it was loaded into.

Only difference is that supervisor would probably restart OTP process, as would
inittab entry on Solaris or daemontools, etc.  In both cases the new code has
to be taken back out and the good version put back in. In both cases the new
code caused a problem. Though the entire application may not have gone down in
the OTP realm, that may not mean that it can function normally (or at all).

My point is that there is NOT a big difference between the two, and that is
how Martin should approach the sales pitch with C/C++ guys who argue against
hot-code load but are all for shared objects.

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

Well, yes and no.  That is no different than putting an extra node into a 
data structure passed in C/C++ IMO. The basic interface MUST remain the same
in both cases, but can be modified via the actual data passed in, also in
both cases. Again, my point being that there is no real difference between
Erlang/OTP hot code load and C/C++ shared object loading, so Martin's
sales pitch can include this fact. Under this light, the idea of hot code load
is NOT all that crazy.

-Rick