Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!blars!blarson
From: blarson@blars
Newsgroups: comp.unix.internals
Subject: Re: Shared Library Objectives (Was: Shared Lib Question (ISC))
Message-ID: <201@blars>
Date: 14 May 91 07:46:51 GMT
References: <162@titccy.cc.titech.ac.jp> <1991May11.011213.4846@NCoast.ORG> <1991May13.144438.21103@sco.COM>
Sender: news@usc
Reply-To: blarson@usc.edu
Lines: 57
Nntp-Posting-Host: dianne.usc.edu
Originator: blarson@dianne.usc.edu

In article <1991May13.144438.21103@sco.COM> larryp@sco.COM (Larry Philps) writes:

Hmm, let's compare Primos shared libraries...

>    1) Ability to easily create a shared library:
>	yes)  Do it like Sun, pic code and dynamic linking
Yes.  Creating a shared libarary takes one or two more linker command
than a normal program.

>    2) Fast Startup times:
>	yes)  Do it like ATT, no pic code, no dynamic linking, exec
>	      just sets up the regions and lets it rip.
>	no)   Don't worry about it, let ld.so (or whatever) run, and
>	      set things up.

Sort-of.  Start-up is reasonably fast, but the first time each shared
routine is called it is dynamicly linked.  Registered EPFs are
available at Rev 23 to allow pre-linking of frequently run programs.
(At cost of some of the other points.)

>    3) Fast execution:
>	yes)  Most processors run pic code slower than absolute code,
>	      so you probably pick the absolute method.

Yes.  Reasonably written segmented code doesn't care which segment it
is loaded in.

>    4) Maximum Memory sharing between processes
>	yes)  pic and absolute code should be equivalent if you are
>	      clever.  Ensure the dynamic linker does not fault in most
>	      of the library while patching global data addresses.
Yes.

>    5) Easy maintenance
>	yes)  Want to be able to create new versions easily, update the
>	      libraries with fixes/features without requiring program
>	      recompilation.  Want to be able to link an arbitrary set
>	      of libraries together without worrying about address
>	      conflicts.  Pic and dynamic linking wins here.
Yes.  Also a single user can test out new version without affecting
other users. 

>We did not come up with an implementation that satisfies all the above
>goals.  Anybody know of one?

Primos seems to come close.  A couple of minor details are the
required hardware support (fault bit) and the many other problems of
Primos.   (They still havn't figured out how to do I/O reasonably.)

-- 
blarson@usc.edu
		C news and rn for os9/68k!
-- 
Bob Larson (blars)	blarson@usc.edu			usc!blarson
	Hiding differences does not make them go away.
	Accepting differences makes them unimportant.