NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/unix/bsd/10210

Text File | 1992-12-14 | 4.1 KB | 89 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!spooky!witr
From: [e-mail] (Robert Withrow)
Subject: Re: Shared lib benchmarks, and experiences
Message-ID: <[e-mail]>
Sender: [e-mail] (News Administrator)
Nntp-Posting-Host: spooky
Reply-To: [e-mail]
Organization: R.W. Withrow Associates
References: <veit.724064215@du9ds3> <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: usa
Date: Mon, 14 Dec 1992 23:10:25 GMT
Lines: 74

In article <[e-mail]>,
 [e-mail] (Eric Youngdale) writes:

|     Finally some people are wondering why we are discussing the linux
| shared libraries on the comp.unix.bsd list.  The original question had to do
| with shared experiences, and some people naturally were wondering how we do
| this under linux.

And I think that this discussion is good to have in C.U.B. so that the
technical tradeoffs of shared librarys get a good airing...

| >  1) The two librarys must have identical ``assigned'' addresses, and
| >  2) The two librarys must be substantially identical.
|
|     The first point is correct.  I should point out that there is no reason
| why we cannot have two different libraries assigned to the same address - you
| just will not be able to use both at the same time in the same process.

The reason why I bring this up is that I suspect that it is difficult to
assign ``compatible'' ``assigned'' addresses except in the case where the
libraries are ``substantially identical''.  For example, if the latter library
has twice as many entrypoints as the former, this is likely to be a difficult,
problem and probably has no general solution.

| The second one depends upon how you define "substantially".
[...]
| As a rule of thumb, as long as you can provide identical
| assigned addresses, you can generate plug compatible libraries.  The
| limitations have less to do with the design of the library itself, but have
| more to do with the tools that we have available to ensure that the various
| addresses remain the same from one version to the next.

This is the caveat that worries me.  How do you handle the following
situations?

  1) Second library has (many) more entrypoints than former library.
  2) The ordering of the entrypoints in the objects is different.
  3) There is changed inter- and intra-calling relationships between
     routines in this and other libraries.
  4) What about run-time library loading, as is done with resolvers
     on SVR4.

| As I recall the biggest drawbacks to the dynamic linking were
| the need for a new assembler and linker, the need for more extensive kernel
| mods, larger binaries and more overhead to load a program.

Let's handle these in turn.

1) Need for new assembler and linker:  If you mean that you need a compilation
system that can generate PI code, then yes, you need these.  Since the GCC
system generates PI code, I don't see why this is a problem.

If you mean that you have to extensively modify the compilation system
in other ways, this is not correct.  You can handle all the needed functions
in the CRTL startup code.  You may want to have the linker do other things
for efficiency reasons, but it is not otherwise required.

2) Kernel mods.  Dynamic shared libs can be done without kernel mods
depending on how code space is protected.  Or you can use a mmap primitive
to speed things up.  Or you can add additional kernel code to make it
all more efficient.  Extensive kernel mods are not *required*.

3) Larger binaries:  Not significantly, and, perhaps, not at all.  It depends
on the details.  This should be weighed against the benefits.

4) More overhead to load a program.  This also depends on the details.
On my SVR4 system the additional time varys depending on whether the library
has already been accessed by another process.  For X programs, which access
about a dozen shared librarys, the time seems to be swamped by other factors,
such as widget creation.  I don't notice it.

--
 Robert Withrow, Tel: [phone], Fax: [phone], Net: [e-mail]
 R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA