🚀 go-pugleaf

In article <1991Sep16.231808.9812@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark V. Meuer) writes:

   There is an EXTEMELY annoying glitch with our emacs setup and it is driving me  
   batty!

I've seen this happen on one of our NeXTstation(but not our 040
Cubes), and I've mentioned a few times but no one has ever figured
this out.  HAS ANYONE ELSE WITNESSED THIS PROBLEM?  It makes Emacs
unusable on some NeXTs.
  
   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.

Have you tried upgrading to 18.57? :-) I have some diffs that I
finally got around to applying yesterday that seem to work.  I'll
upload the entire emacs 18.57(diffs applied) plus the diffs in case I
screwed up something.

-Mike

--
------------------------------------------------------------------------------
N    N        X     X TTTTTTT  | melling@cs.psu.edu
NN   N   eeee  X   X     T     | melling@vivaldi.psu.edu (NeXT mail)
N N  N  e    e  X X      T     |----------------------------------------------
N  N N  eeeee   X X      T     |"Medicine will cure death and  government will
N   NN  e      X   X     T     | repeal taxes before Steve [Jobs] will fail."
N    N   eee  X     X    T     |                                  Guy Kawasaki

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

In article <1991Sep18.021603.260@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark V. Meuer) writes:

   [NFS is causing the Emacs find-file problem deleted]

I've never seen this problem happen on any other machine, including
our 50 diskless SLC's.  If you are using a local tmp directory then
the possibility exists of screwing something up.

-Mike

--
------------------------------------------------------------------------------
N    N        X     X TTTTTTT  | melling@cs.psu.edu
NN   N   eeee  X   X     T     | melling@vivaldi.psu.edu (NeXT mail)
N N  N  e    e  X X      T     |----------------------------------------------
N  N N  eeeee   X X      T     |"Medicine will cure death and  government will
N   NN  e      X   X     T     | repeal taxes before Steve [Jobs] will fail."
N    N   eee  X     X    T     |                                  Guy Kawasaki

In article <1991Sep18.021603.260@s1.msi.umn.edu> meuer@roch.geom.umn.edu (Mark V. Meuer) writes:
   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.

   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.

NFS on the NeXT does not do exclusive locks on files, period.  That
might be the reason someone else mentions that they've been doing this
on diskless Suns without problems for some time - maybe Sun's NFS
implements exclusive locks (in fact, considering origins of NFS, I'd
have to bet they do :-).

Later,
--
scott hess                      scott@gac.edu
Independent NeXT Developer      Graduated GAC Undergrad!
<I still speak for nobody>
Old:    PO 829, GAC, St. Peter, MN  56082       (507) 933-8466
New:    RR#4 Box 227 Pipestone, MN  56164       (507) 825-2788