mark.umcp-cs@udel-relay@sri-unix.UUCP (08/01/83)
From: Mark Weiser <mark.umcp-cs@udel-relay> I spent a few minutes looking at the csh background/foreground (sh.proc.c) with which I was already familiar, and then the sh forking code (exe.c), for which it was my first time (so my judgement may be more subject to error here). I didn't come up with a definitive answer, but looking reminded me of two things going on when a SIGTSTP occurs in a child with which the sh may be unprepared to deal. 1. There are lots of extra signals floating around, SIGCHLD for instance. It looks like this should not cause any problems since it defaults to nothing, but the 'sh' of course does nothing to prepare for it. 2. The csh (and wsh and other shell-like code using process control) ordinarily hand over the control terminal to the forground process, and then grab it back when something happens to the foreground program. Signals bouncing around go to everyone in the same process group as the control terminal, which will exclude the csh, but will include the sh (since it did nothing to put anyone in any other process group since it doesn't know about process groups). This will aggravate the problems of (1) since all the extra signals will truly by zipping around. Of course, this doesn't really explain things, but I promise I won't say "if you would only use the csh...".
JPAYNE@BBNG.ARPA (08/01/83)
I'm confused. I tried Pausing emacs under /bin/sh and emacs simply returned immediately and repainted the screen. Does this means that the kernel didn't send the signal to the shell? Hey! Wait a minute. The kernel remembers whether or not the new signal mechanism has been used in any way (there is actual a flags somewhere in the u structure I think). It needs to know so it can do the "right" thing with interrupting certain system calls (read/write/wait). Perhaps the kernel refuses to send signals greater than 16, when the new mechanism hasn't been used, so that old programs don't break. SO lets see ... when a program that uses sigset etc. (which sets the flags in the u structure) decides to kill its process group, the kernel says "Okay fine. Lets SIGTSTP the processes in the current process group (which includes the sh)", and then both processes are sleeping. Sound plausible? or am I still confused?
chris%umcp-cs%udel-relay@sri-unix.UUCP (08/02/83)
From: Chris Torek <chris%umcp-cs@udel-relay> From: JPAYNE@BBNG ... I tried Pausing emacs under /bin/sh and emacs simply returned immediately and repainted the screen. ... The kernel remembers whether or not the new signal mechanism has been used in any way .... Perhaps the kernel refuses to send signals greater than 16, when the new mechanism hasn't been used, so that old programs don't break. ... when a program that uses sigset etc. decides to kill its process group, the kernel says "Okay ...." Sound plausible? or am I still confused? That was my initial thought. However, your first example disproves it. Emacs uses the new signal mechanism! Also, I took a look into the kernel code and came up with ... nothing. The code which sends signals just calls psignal on the appropriate processes. There may be something special in psignal; it'll take more digging on my part before I'm sure. - Chris
dbj.rice@rand-relay@sri-unix.UUCP (08/03/83)
From: Dave Johnson <dbj.rice@rand-relay>
From: JPAYNE@BBNG
... I tried Pausing emacs under /bin/sh and emacs simply
returned immediately and repainted the screen. ... Perhaps
the kernel refuses to send signals greater than 16, when the
new mechanism hasn't been used, so that old programs don't break.
From: chris@umcp-cs
... I took a look into the kernel code and came up with ...
nothing ... There may be something special in psignal ...
The reason this happens is simple: SIGTSTP is ignored by login, which is
inherited by the /bin/sh, and is then inherited by the Emacs. When emacs
decides that you're trying to do a pause-emacs, it sends itself a SIGTSTP.
Since this is ignored in the case that you're running the Emacs from /bin/sh
(without a csh behind it), the signal does nothing. When emacs wakes back
up from the pause (which in this case is immediate since the pause was
ignored), it redraws the screen. The reason this behaves differently when
you login to csh instead of sh is that the C-shell sets the action for
SIGTSTP back to SIG_DFL when it starts up.
Dave Johnson
Dept. of Math Science
Rice University
dbj.rice@Rand-Relay