🚀 go-pugleaf

In article <1991Sep16.231808.9812@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark  
V. Meuer) writes:
> 
>I have a NeXT with version 2.1 of the system.  We have emacs 18.55 running.  
>(Please don't tell me to upgrade to version 18.57 unless you can also supply a  
>pointer to diffs or at least s- and m- files for the NeXT.)  There are several  
>machines in our network and we are using yellow pages.  The problems is that  
>whenever I try to find a file (either through "C-x C-f", "emacs file" or  
>through a client talking to the server) emacs freezes completely for between  
15  
>and 30 seconds.  The file then loads and everything works fine.  In about 1 in  
>10 times the file loads immediately with no delay at all.

Several people sent me suggestions (thank you!), but the obnoxious delay 
was finally explained and corrected by Scott Bertilson, one of the
really smart people who works here at the Center.

For people who have had this problem, one quick hack to correct it is to make  
/usr/lib/emacs/lock be a symbolic link to /tmp.  The full explaination follows.

I was able to track down that there was a file called
!!!SuperLock!!! in /usr/lib/emacs/lock, and when that file existed the
delay would occur.  When that file wasn't there, neither was the
delay (usually).  

We found the segment of code that was causing the problem. When emacs
tries to open a file to edit, it tries to do an exclusive create on
the superlock file.  If the exclusive create fails, it tries 19 more
times with a one second delay between each try.  After 20 tries it
just ignores the lock file being there and opens the file the user
wanted.  If it succeeds in creating the lock file, it opens the user's
file and then immediately removes the lock file.

The problem we had was that /usr/lib/emacs/lock was mounted over NFS,
and apparently NFS doesn't handle exclusive create as well as one
would hope.  The command would create the file, but return an error
saying it didn't.  Since emacs thinks it wasn't able to create the
lock file, it never removes it.  But since it did create the file, all
future attempts to open files encounter this lock file and force
emacs to go through a 20 second loop before proceeding.  That was what
was causing the delay.

The hack we used to cure this problem was to make /usr/lib/emacs/lock
be a symbolic link to /tmp, so that it would always point to a local
directory and avoid the NFS exclusive create bug.  I know this is far from  
perfect, but so far it is working correctly.

Thanks to everyone who responded to my plea for help.  It's nice to
know that there are so many friendly people on the net.

-mark
--
Mark Meuer   <><    |   The Geometry Center   |   meuer@geom.umn.edu
"Given automated support for a notation, one of the things that tools
can do is to help bad designers create ghastly designs much more
quickly than they ever could in the past." -- Grady Booch