🚀 go-pugleaf

In article <RICH.90Mar29013720@sendai.sendai.ann-arbor.mi.us> rich@sendai.ann-arbor.mi.us writes:
>In article <9003230533.AA01827@LOM1.MATH.YALE.EDU> ara@LOM1.MATH.YALE.EDU (Allan Adler) writes:
>
>   We are using emacs on sun3's and sparcs. When several people are
>   using emacs at the same time, the machine slows down to a crawl. I
>   think that is because multiple copies of emacs are being loaded
>   into memory.
>
>In any case, your problem clearly involves too little memory for the
>intended applications.

Quite likely.

>Making the executable sharable isn't believed possible as there is too
>much that changes on a per-instance basis.  I think what would be
>needed, is an executable format with facilities for BOTH shared and
>private code, which few unix's have.

Not true. All unix's (from version 7 I think) make the text segment
shareable by default. The data segment on system 5 based machines is
also shareable on a copy on right basis. That is, two instances A and
B of /usr/local/bin/emacs are running. There should only be one copy
in memory of the text segment, and on a SysV system there will be
initially only one copy of the data segment. On SysV, when process A
writes to a page of the data segment that page the kernel makes a copy
of that page only.

Emacs is designed to exploit this feature when it unexecs its self.
The lisp to be preloaded is loaded into an area in the running temacs
data segment. When emacs unexecs itself, it adjusts the text/data
boundary so that the preloaded lisp becomes part of the text segment
of the resulting xemacs. Thus all the C code and all the preloaded lisp
is ineffect shareable.

You can reduce the amount of memory consumed by multiple emacs users
by arranging that any widely used lisp packages are preloaded. You
create a file (called siteinit.el I think) which loads various things
and increase PURESIZE.

>I don't believe that anyone else has bothered, but you might try
>picking a subset of emacs and compiling it with suns position
>independant stuff and making it into a shared library.

I would expect this to be a totally fruitless exercise. The size of
the emacs exectable *file* would go down but the total disk space
(including the foo.so) would be the same or slightly more. The amount
of memory used would be the same or slightly more. Dynamic linking is
only a win when there are multiple executable files using the same
library functions. There is no benefit to multiple instances of only
one executable file using those library functions.

-- 
Ian Dall     life (n). A sexually transmitted disease which afflicts
                       some people more severely than others.