Does GNU emacs ever use shared libraries?

Israel Pinkas ~ pinkas at hobbit.intel.com
Mon May 15 11:02:59 AEST 1989


In article <152 at talarian.UUCP> scott at talarian.UUCP (Scott Weitzenkamp) writes:

>   I noticed that on SunOS 4.0, GNU emacs uses the -Bstatic flag to cc
> to prevent the use of shared libraries.  Does GNU emacs ever use 
> shared libraries?  If not, why not?  Does System V have an option
> like -Bstatic to prevent the use of shared libraries?

I posted about this before, but I realized that there was one more thing to
consider.  Efficiency.

SunOS 4.0 executables do not swap text pages by default (-z flag to ld).
They are released from memory and marked as not present.  If needed again,
they are loaded from the disk image.  If the original image is on an NFS
mounted partition, every page fault results in an NFS access.  This hurts
performance on large processes.  (We improved performace on our X10 server
by linking with -n by 100%.)

Two other problems with this demand paging are:

1) If the file server becomes unavailable (crashes, times out, etc.) the
page fault can fail and the process can hang.  The network is flooded with
NFS requests, which slows down everybody.

2) If the image is deleted, everything goes haywire.  This can happen with
any type of demand paging, but the type in SunOS 4.0 just exacerbates the
problem, becaus the same page can be loaded many times.  (I know, this is
stupid, but it happens occasionally.  I didn't think that anybody would
leave an Emacs process around for more than a week, but guess what?)

The above are both problems with NFS, but dynamic libraries just add to the
confusion.

-Israel
--
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation.  In no way should the above be taken
to be a statement of Intel.

UUCP:	{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas
ARPA:	pinkas%cadev4.intel.com at relay.cs.net
CSNET:	pinkas at cadev4.intel.com



More information about the Comp.unix.questions mailing list