🚀 go-pugleaf

Relay-Version: VMS News - V6.0 1/9/90 VAX/VMS V5.3; site kontu.utu.fi
Path: kontu.utu.fi!polaris.utu.fi!news.funet.fi!sunic!mcsun!uunet!snorkelwacker!tut.cis.ohio-state.edu!relay.eu.net!nixpbe!uucp
Newsgroups: gnu.emacs.bug
Subject: (none)
Message-ID: <9010152158.AW20088@unido.informatik.uni-dortmund.de>
From: nixpbe!uucp@relay.eu.net
Date: 15 Oct 90 21:58:20 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: Gnus Not Usenet
Approved: bug-gnu-emacs@prep.ai.mit.edu
Lines: 86

>From uucp Mon Oct 15 19:46 WST 1990 remote from nixsin
To: nixpbe!unido!gnu-emacs-bug
Path: nixsin!nixpbe!unido!mcsun!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!FIG.CRAY.COM!jot
From: jot@FIG.CRAY.COM (Otto Tennant)
Newsgroups: gnu.emacs.bug
Subject: no subject (file transmission)
Message-ID: <9010012133.AA02951@fig12.cray.com>
Date: 1 Oct 90 21:32:59 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 71
Posted: Mon Oct  1 22:32:59 1990


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.)