🚀 go-pugleaf

>>>>> On 24 Apr 91 01:20:52 GMT, kyle@wendy-fate.uu.net said:

kyle> Daniel Jacobson writes:
 > I am trying to say that I have a special situation due to UTS Unix or
 > something, where I type "g" to get new mail, and vm hangs, so i hit
 > ^G.  [the new message has been appended to INBOX at this point, and
 > $MAIL is now empty] then i hit "g" and get a `no new mail' message.  i
 > have to send myself mail & try again until i dont hang [50% of the
 > time]...
 > 
 > all i ask is that no matter when one hits ^G, there shouldn't be a
 > state where INBOX can be already appended too [by VM], but the summary
 > buffer denys it...

kyle> This is going to be tough to do.  If I use any more inhibit-quit's
kyle> inside VM, the core dumps and train schedules are going to start
kyle> arriving in my mailbox again... :-)

[train schedules?]

I'm afraid you're right.  At least now i've never lost mail... any
more tinkering and....???

kyle> Better would be to figure out what it is about Emacs' subprocess code
kyle> that gives your UNIX grief and fix it. what kind of hang are we
kyle> talking about here.  Child dies but parent doesn't notice?

Well, "it might go away when we move to uts 3 from 5.2.6b", but just
for the curious, here's the scoop.  [I don't expect we need to
drag this thread further... i just want to mention the below for
'completeness'... ---over & out---]

--------------------------

[THE COMMANDS-SOMETIMES-STICK-ON-IBM/AMDAHL BUG ]

From: jot@FIG.CRAY.COM (Otto Tennant)
Date: 10/1/1990
Newsgroups: gnu.emacs.bug

No one here (Cray Research) seems to have an opinion.  Thanks to 
Mr. Stallman posting a note, I learned of bug-gnu-emacs.  

I posted this to "local.mendota-only" and "local.emacs" a day or so a
go and got no response.  I really am interested in this topic.
Perhaps those of you who receive this by e-mail can forward it to
other folks you know who might have an opinion.


        A QUESTION ABOUT UNICOS AND EMACS


The first "production" release of GNU Emacs for UNICOS will
be included with UNICOS 6.0.  As we were preparing the
product, we found that Emacs would hang intermittently
whenever one attempted a 'dired' or 'man' command.
"Intermittent" here just means "not every time."  The hangs
were frequent enough to make the implementation useless.

We are pretty sure what the problem is.  UNICOS is a "USG"
type system (whatever that means.)  However, if we are
correct, the problem should occur with greater or lesser
frequency on any "USG" type system.

Under normal circumstances, Emacs is prepared to handle the
SIGCLD signal (death of a child process) with a little
routine which calls 'wait3' and then re-establishes itself
as the signal handler.  (This is routine 'sig_chld'.)  So
far as I can tell, this is morally equivalent to discarding
the signal and the zombie process into which the child may
have been transformed.

As Emacs is preparing to fork a child process to run, for
example, an 'ls' command, it changes the SIGCLD handler to
SIG_DFL, the default value.  This means that when a child
process terminates, it will be transformed into a zombie and
the event will *not* be signalled.

After the fork, the parent does a minor bit of housekeeping
and then re-establishes the original signal handler.  In the
normal course of events, it calls a routine named
'wait_for_termination' to await the completion of the child
process.  

The 'wait_for_termination' routine enters a loop in which it
checks to see if the process id it has remains valid.  The
only way out of this loop is for the process id to become
invalid. 

However, it appears to be possible for the child process to
execute, terminate, and be transformed into a zombie before
the parent has a chance to re-establish the old signal
handler.  This means that the process id will never become
invalid, since nothing will ever happen to kick Emacs out of
its 'wait_for_termination' loop.

This behaviour should be possible on any "USG" type
implementation.  Of course, the relative speed of execution
of the two processes can be affected by exogenous factors
including memory availability, swapping devices, and
scheduler policies.  We do not understand why this failure
should strike UNICOS 6.0 with such a high frequency.

Does anyone have any suggestions which might confirm our
refute our hypothesis?

(Oh, our fix.  We took out all of the signal handling stuff
and changed 'wait_for_termination' to simply call 'waitpid'.
I suspect that 'wait_for_termination' was written as it was
in the hope that a ^G would break the loop; it won't, so no
real functionality has been lost.)

Date: Wed,  3 Oct 90 09:36:34 CDT
From: danj1@ihlpa.att.com (Daniel Jacobson)
Distribution: gnu
Organization: GNUs Not Usenet

>>>>> On 1 Oct 90 21:32:59 GMT, jot@FIG.CRAY.COM (Otto Tennant) said:

Otto> product, we found that Emacs would hang intermittently
Otto> whenever one attempted a 'dired' or 'man' command.
Otto> "Intermittent" here just means "not every time."  The hangs
Otto> were frequent enough to make the implementation useless.
Well, for us it's "hit ^G and try again"

Otto> We are pretty sure what the problem is.  UNICOS is a "USG"
Otto> type system (whatever that means.)  However, if we are
Otto> correct, the problem should occur with greater or lesser
Otto> frequency on any "USG" type system.

Yes, this is what we have in our local tips file:

|in 3/1990 Boris_B_Kofman@ATT.COM wrote:
|>I am using [exptools] GNU Emacs 18.55. Every so often a function hangs. 
|>This most often happens to 'vm', when it starts getting new mail, 
|>but never finishes. I've  also seen 'dired' and 'rmail' hang.
|>Does anybody else have that problem? Any idea what the fix is?
|
|Yeah, I bet you're using an Amdahl/IBM, we thought we had a fix, but no,
|no fix.  There is also something called, I believe, `Doug Gwyn's
|directory accessing functions for System V,' but this is a big effort
|or we have to be superuser or something...
|
|For now I just use Control-G [once], then do my command again...  when
|it stalls sending mail in VM I check to see if the mail got sent with
|"fgrep $LOGNAME /usr/mail/mail.log | tail" from a shell.  It usually
|did get sent, so I then kill the "*mail*" buffer.  Of course there are
|other mail sending variable settings you should use for now too, like
|mail-interactive and vm-strip-reply-headers... see the other tips
|directory files.
|
|Other potential hangers on an Amdahl/IBM (do a Control-G and try again):
|Dired (C-x d), shell-command (M-!), shell-command-on-region (M-|),
|ispell stuff.

Oh, the Amdahl's `uname` says "uts ihlpa 5.2.6b 5 5890" a localism,
meaning based on "SYS V.2" with some SYS V.3 add-on's or something.

It doesn't seem to occur on System V "3.2.2 3 3B2" (`uname` output).

[I'm just reporting the symptoms.]

>>>>> On Tue, 8 Jan 91 20:24:06 -0500, rms@ai.mit.edu (Richard Stallman) said:

Richard> It seems clear that what hangs is the call-process function.  Perhaps
Richard> a Unix wizard (of which you must have many) would be able to figure
Richard> out why.

[DANJ1:]
Well, I'll post this on our local netnews, catching more attention
that way... but I doubt Mr./Ms. Miracle Woman/Man will come to our
rescue... as we also don't have a super record of attending to local
gnuemacs repairs too...

JAN 15 1991: Larry A. Shurr (att!cbnmva!las)
I wish I were that Miracle Man... unfortunately, I'm not and I'm
having this problem on VAX Sys V running on our SMP VAXen.  Help!!!
I, too, can ^G and try again, it's just a damned nuisance.

Dan J. Sun Mar 17 20:23:09 CST 1991: Hope seems on the horizon, as the
netnews machines are System V.3, without this bug... so perhaps when
one upgrades to "RDS UNIX SYS V.3" this problem goes away [?]