Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!oracle!jcreight
From: jcreight@oracle.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Big Programs Hurt Performance
Message-ID: <339@oracle.UUCP>
Date: Fri, 2-Oct-87 03:36:40 EDT
Article-I.D.: oracle.339
Posted: Fri Oct  2 03:36:40 1987
Date-Received: Sat, 3-Oct-87 09:00:57 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM) <8579@utzoo.UUCP) <6886@eddie.MIT.EDU) <4754@ncoast.UUCP>
Organization: Oracle Corporation, Belmont, CA
Lines: 30
Summary: Shared libraries eat shared memory?

In article <4754@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes:
> As quoted from <2501@xanth.UUCP> by kyle@xanth.UUCP (Kyle Jones):
> +---------------
> | In <14888@topaz.rutgers.edu>, hedrick@topaz.rutgers.edu (Charles Hedrick) sez:
> | > What you really want is shared libraries.  That way, only one copy
> | > of the code is shared by all programs that use it, but you can
> | > change it.
> | 
> | This doesn't sound much different from the current scheme.  The
> | advantage of having the window system in protected RAM is that you
> | don't have gargantuan executables for small programs; calls to system
> | tools are simply linked to their known entry points in memory.
> +---------------
> 
> The first program run which uses the shared library allocates a shared memory
> segment at process address 0x300000 and copies /lib/shlib into it.  The
> program is linked with a special crt0.o which does the shm attach and load
> (if necessary), and with a loader "ifile" (instruction file, a System V
> feature which gives fine control over an object file) which defines the
> addresses of routines in /lib/shlib with origin 0x300000, read-only data
> also within the shlib, and read-write data which is allocated at a fixed
> address just below the shlib.  

Does this mean that each process that is running using shared libraries
consumes one shared memory segment?  There is a (rather low) kernel limit
on the number of shared memory segments that may be attatched systemwide,
as I recall.  What happens when you run a shared-library program and
there aren't any shared memory segments left?
					JC
					hplabs!oracle!jcreight