Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Shared Lib Question (ISC)
Message-ID: <19282@rpp386.cactus.org>
Date: 16 May 91 15:05:39 GMT
References: <174@titccy.cc.titech.ac.jp> <19256@rpp386.cactus.org> <7516@segue.segue.com> <14213:May1522:13:2291@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cat Emporium and BBQ Grill
Lines: 81
X-Clever-Slogan: Help Prevent Robbery.  Tax the IRS.

In article <14213:May1522:13:2291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Yeah. I've been arguing this with John via e-mail. He keeps repeating
>the same old description of how to separate a library into a sharable
>part and the part with the global variables. I keep pointing out that
>the global variables are still there. We all know how to write a shared
>library under the *constraint* of no static data, but the issue here is
>whether that is a real constraint---i.e., whether good libraries can use
>globals. John keeps ignoring the fact that malloc() does use globals.

Oh.  If you argue that there is no real need to have global static
data removed from the library, sure, in the absolute sense there is
no real need to do that.  All you need is a dynamic loader in the
kernel can fix up all the references and create the additional data
space on the fly as needed.  And I'm not ignoring anything, I've
already said that yes, malloc() uses globals, and pretty much has
to given its currently implementation.  It preserves state across
invocations, and that pretty much requires some static data somewheres
to handle.

>C'mon, John, would you just admit that eliminating global variables is
>not always a good idea, and that requiring that shared libraries be pure
>is a real constraint?

I don't know, I think the performance loss due to dynamic binding
might be the real constraint - constraint to future sales, that is.

>Even worse, it requires that any library routine that might *use* one of
>those malloc-using routines must also take the pointer. So much for
>separating interface from implementation.

Nope.  All that is needed is for the other routines to know how to
find the external interface to the malloc command.  Put a jump table
at a well-known address, and the internal routines are free to
invoke malloc via its external interface.  This even works if you
supply your own malloc() routine - the jump table, which resides
in your address space, get fixed up by the binder or loader or
wherever you want to defer the problem off to.

>Even worse than that, if you want to keep the same interface forever,
>you have to predict all libraries that the implementation might use,
>directly or indirectly, not just now but in the far future. So much for
>finite argument lists. :-(

Glad to see that the implementations I've seen don't have that
problem.  That could be pretty tough to get around ;-)

>> It is far better to either keep a register pointing to a global data area,
>> as mentioned in my previous note, or to support shared libraries with
>> private data, with all the attendant complexity, than to cripple a library
>> specification on the basis of a misapplication of CS principles.
>
>Amen.

I do have to agree that using a register to point to global data is
a very good idea.  My only complaint is that you have to include so
much global data ...

I saw Larry McEvoy's (right name, right person?) posting regarding SunOS's
loader speed and don't exactly think we want to make it worse by having
more address fixups needed.

But seriously, you aren't crippling anything.  Last time I checked,
which was 5 years ago, the library scheme that John Bremsteller did
at Pinnacle had none of these problems.  It did have others, but that
was 5 years ago when no one knew what we were getting into.  I don't
know if it is still being used by them, they sacked me on 1/1/87,
but it worked just fine in my office on my desk for the short time
I was there playing with it.  Not counting me (because I was working
for the "marketing department"), there were two other UNIX programmers
there and they managed to get some "shared library" scheme working in
just a few weeks.  It really isn't that hard.  The original prototype
I worked up took me less than a week, and I had half the library or
more shared in that time.  I think the other John finished the idea
off in just a few more weeks of work, along with his other work load.
It really wasn't that hard, and it solved quite a few of the "hard"
problems that Dan dreams up.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."