Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William Sommerfeld)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Message-ID: <3581@bloom-beacon.MIT.EDU>
Date: 9 Mar 88 01:11:57 GMT
References: <497@aimt.UUCP> <5257@well.UUCP> <2984@metavax.UUCP> <2985@metavax.UUCP> <34359UH2@PSUVM> <667@kajak.cs.vu.nl>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 25

In article <667@kajak.cs.vu.nl> jos@cs.vu.nl (Jos Warmer) writes:
>    Replacing shared libraries with new versions could make
>    lots of working programs crash.  Because those libraries are
>    instantaneously used in almost ALL running programs, one
>    error in such a library can be fatal for the complete system.

A properly designed shared library system should deal gracefully with
version skew.

Ideally, the installation of a new library should be done such that
existing processes can continue to use the old version of the library,
while new processes which start up see the new version.

Also, there should be a facility to allow just one process to run with
a new version of a shared library, to test compatibility with the old
version, although this is less important in a single-user workstation
environment than in a timesharing environment.

All this implies that the interface to the routines is unchanged, and
that only the _implementation_ of the library is changed in the new
version; changing the interface of a library routine will be painful
unless you've had the foresight to include some sort of version
numbering system.

					- Bill