🚀 go-pugleaf

>From uucp Mon Oct 15 19:32 WST 1990 remote from nixsin
To: nixpbe!unido!gnu-emacs-bug
Path: nixsin!nixpbe!nixbur!linus!agate!apple!julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!yale!cmcl2!lanl!beta.lanl.gov!scp
From: scp@acl.lanl.gov (Stephen C. Pope)
Newsgroups: gnu.emacs.bug
Subject: Re: A spin loop problem and a core dump problem
Message-ID: <SCP.90Oct1134600@grizzly.acl.lanl.gov>
Date: 1 Oct 90 19:46:00 GMT
References: <9009281610.AA21678@s2.Morgan.COM>
Sender: news@lanl.gov
Reply-To: scp@acl.lanl.gov
Organization: Advanced Computing Lab, LANL, NM
Lines: 44
In-reply-to: sachs@morgan.com's message of 28 Sep 90 16:10:00 GMT




on 28 Sep 90 16:10:00 GMT,
sachs@morgan.com (Josef Sachs) said:

Josef> I've been using Gnu Emacs for three years without a hitch until two
Josef> problems occurred this week:

Josef> (1) This one's happened a few times, but I can't reproduce it.
Josef>     On my Sun 3-110 at home, I connect via SLIP to one of our
Josef>     Solbourne 5/600's at work through a Cisco terminal server.
Josef>     While running an Emacs on the Solbourne with the Sun used
Josef>     as the DISPLAY device, the line drops.  When I reconnect,
Josef>     I find the Emacs is in a spin loop.  According to trace:

Josef>     s7$ trace -p 12542
Josef>     Process 12542 attached - interrupt to quit
Josef>     ioctl (0, 0x4004667f, 0xf7ffdc94) = -1 ENODEV (No such device)
Josef>     sigcleanup () = 0
Josef>     select (32, 0xf7fff6dc, 0, 0xf7fff6d8, 0xf7fff6c8) = 2
Josef>     getpid () = 12542
Josef>     kill (12542, 23) = 0
Josef>     - SIGIO (23)
Josef>     ioctl (0, 0x4004667f, 0xf7ffdc94) = -1 ENODEV (No such device)
Josef>     sigcleanup () = 0
Josef>     select (32, 0xf7fff6dc, 0, 0xf7fff6d8, 0xf7fff6c8) = 2
Josef>     getpid () = 12542
Josef>     kill (12542, 23) = 0
Josef>     - SIGIO (23)

Josef>     Looks like Emacs somehow had trouble dealing with the loss of
Josef>     the connection to the X server?

...

Yes, I've seen this problem with 18.55 on a local Ultrix 3.1 vax and
various sparc machines running both 4.0.3 and 4.1, where the DISPLAY
device is distant (Livermore).  Our traces look the same.  It's
a problem because the emacs process just eats up CPU time.  Any hope
that this'll be gone in v19?

stephen pope
advanced computing lab, lanl
scp@acl.lanl.gov