Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Handling and run-time libraries
Message-ID: <16128@sun.uucp>
Date: Fri, 3-Apr-87 14:17:24 EST
Article-I.D.: sun.16128
Posted: Fri Apr  3 14:17:24 1987
Date-Received: Sun, 5-Apr-87 06:43:04 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <6042@mimsy.UUCP> <16014@sun.uucp> <291@pembina.alberta.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 25
Xref: utgpu comp.arch:772 comp.lang.c:1455

>SVID specifies shared memory.  The point is that having shared
>memory implies ease of shared library implementation but not
>vice versa.

Note that the shared libraries implemented in System V, Release 3 do
*!NOT!* use the SVID shared memory mechanism.  Maybe AT&T did the
wrong thing here, maybe not, but they did, at one point, have an
implementation that had shared memory but not shared libraries, and
now have an implementation with shared libraries and shared memory
but do not use the shared memory system calls to provide shared
libraries.  (Note that S5R3 shared memory can't be write-protected;
this may have had something to do with their decision not to use
it....)

>If I end up working at a Sun shop when I finish my degree here (about
>two months from now), and Sun does not deliver shared libraries at
>the time they distribute an OS with shared memory, you can be sure
>that I will implement same right away.

Sun *already* distributes an OS with SVID-compatible shared memory,
although shared memory segments are currently wired down.  This may
change in a future release.  Most of the work in implementing shared
libraries is, as somebody here put it, in the "libraries" part, not
the "shared" part.  Shared memory may be necessary, but it's far from
sufficient.