Re: Q: shared libraries

In article <58sl5q$l0@knot.queensu.ca>, guest <?@?> writes >In <580mpu$tcj@nntp.idgonline.no> <Nils.Myklebust@idg.no> (Nils Myklebust) >wrote: >: The only tiny problem I have with shared libraries is the small added >: management of making sure the shared libraries are available at >: runtime. I have no experience on this, and it may be insignificant. >: However so is the space we would save using shared libraries. Our >: executables take up about 80 MB althogether, but that's insignificant >: in itself with todays cheap disks, and particularly when you compare >: to the typical database size we have. >: > > I read this ten days after its posting. However, it seems you were > speaking from last decade. If you didn't point out, I would almost > forget shared libraries might have been partly used for saving disk > space in stone age of this industry. It's still a usefully saving... > > Nowadays, have nothing to do with your reason of using shared libraries, > most unix and database engine/server vendors and users supply and use > shared library mainly for following reasons(far away from a complete > list and likely to be wrong and bad as you may point out): > > 1. reducing duplicated job on loading identical program text/data/.. > segments and thus speeding up the program startup. Please, think > about if csh, ksh, bsh are built without using shared library. > Yes. > > 2. reduce process size(not only program size). This will reduce the job > (and speed up) of memory paging(or swapping on old system) as well as > reduce the page consumption. Think about if informix server was built > without using shared libraries and 100 process instances were spawned > from it(typical db server text/data/.. segment size without using > shared library will be 2 to 10 Mb). This is usually the main reason. > > 3. upgrading/patching (PIC)libraries without affecting applications(i.e. > without relink the applications). > This is a sensible idea. At work we have an application with > 100 executables which uses a single library. At the moment if a library function is fixed/changed we just recompile binaries where an obvious problem exists (changes so far have always been forward compatible. It would make so much more sense here to use a shared library to avoid the need to relink. > 4. extending application by users(such as loadable extending C-code SQL > functions in Informix Univerisal Server and Postgres95, etc.). > Apparently DNS on Sun workstations works like this. There are several method of doing name resolution (/etc/hosts, bind, NIS). The required functions are loaded at runtime by explictly loading the required shared library. (All functions within each shared library take the same parameters and have the same return type. > Of cause, with next century's cheap high speed cpu and ram, people will > possibly not bother to use shared library for above reasons. > > -g > I would have thought that 3/4 will always make sense. They allow librarys to be dynamically upgraded and existing code to be extended. Also 2 should nearly always make sense unless we get amazingly fast disk drives. -- David Williams