FAQ terminology harmonisation

Rick Pettit rpettit@REDACTED
Thu Apr 3 18:31:20 CEST 2003

On Thu, Apr 03, 2003 at 08:05:26AM +0100, Peter-Henry Mander wrote:
> May I join in?

Of course you may ;-)

> The hot-swap in Erlang operates differently to shared library reloading 
> in one aspect which I think you overlooked: *both* the old and new 
> versions of a hot-loaded module will run in a live system *until* all 
> the code relying on the module have come to a suitable switching point.

Agreed. I realized this after my post. In either case, as I mentioned to Chris
in a previous mailing, my intent was to strengthen Martin's argument by playing
the other side.

> or run, so it may not even work, so spank me :-)

Would you settle for me "excusing you" :-)

> The difference between cases A and B is that in case B the server code 
> will be swapped with a new version if one was loaded at that time 
> *without stopping*, whereas case A would continue to use the old version 
> regardless.

Agreed. In my (pthread) applications I would need to synchronize the load/unload
via mutex locking, and would NOT be able to easily use a new shared object
while finishing up with the old one. I can almost invision an insane way to 
try to do so, but it would involve terrible obfuscation as the two modules
could NOT share the same symbols and still exist in the same process at the
same time, AFAIK. This certainly is a limitation (you getting this, Martin?)

> I believe that reloading shared libraries will require a fair amount of 
> runtime code management programmed by hand, and I'm not sure that loops 
> like this one can be swapped without stopping the server momentarily. 
> The Erlang version simply never stops, never loses any server state.

Agreed. A familiarity with libdl and the dynamic loader is a must to even get
off the ground. Erlangers never need to know about such gory details.

> I think that the hot-swapping in Erlang is almost (not quite) implicitly 
> supported, whereas C/C++ the extra work involved in implementing and 
> debugging such a feature just gets in the way of solving more 
> interesting problems.

Once again, I am in agreement. I must say I am quite happy with the results of
my posting, as this discussion has both cleared a few things up for me and
given Martin more ammo for his argument with the "LM".


More information about the erlang-questions mailing list