carroll@s.cs.uiuc.edu (10/26/88)
/* Written 8:20 pm Oct 23, 1988 by pjh@mccc.UUCP in s.cs.uiuc.edu:comp.unix.questions */ /* ---------- "Signals" ---------- */ > 1) What is signal 0? It is a 'psuedo' signal, used by Bourne Shell and Korn Shell to mean 'the shell is exiting normally'. Although you can set traps on it, they are caught by mechanisms other than normal signal handling. > 2) What signal does ^d (the logout key) generate? As above, it generates the 'signal' 0. This has no meaning except for traps set on 0. Since you refered to it as the 'logout' key (and not the end-of-file key), I assume that you were asking about how it interacts with a shell. For a normal program, it doesn't generate any signal. Alan M. Carroll "How many danger signs did you ignore? carroll@s.cs.uiuc.edu How many times had you heard it all before?" - AP&EW CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carroll
pete@titan.titan.rice.edu (Pete Keleher) (02/08/89)
I'm trying to write a simple implementation of an Unix shell to be used as a lab in a class, but I'm having problems handling ^Z. I install a handler for SIGTSTP via 'signal' and then send SIGSTOP to the proper child via 'kill'. 'ps' says at this point the child is stopped and soon swaps out. The parent is marked as sleeping. A 'printf' call followed by a fflusch call immediately follows the 'kill', but it never happens. Clues? Comments? --pete -- =========================================================================== Pete Keleher pete@titan.rice.edu Rice University knows nuttin about what I say, or what I do ... ===========================================================================
shirono@hcx3.SSD.HARRIS.COM (02/10/89)
In comp.unix.questions, pete@titan.titan.rice.edu writes: > I'm trying to write a simple implementation of an Unix shell to be used as a > lab in a class, but I'm having problems handling ^Z. > > I install a handler for SIGTSTP via 'signal' and then send SIGSTOP to the > proper child via 'kill'. 'ps' says at this point the child is stopped and > soon swaps out. The parent is marked as sleeping. A 'printf' call followed > by a fflusch call immediately follows the 'kill', but it never happens. ^ First, remember it is not necessarily ^Z. It is whatever you told the terminal driver to interpret as the suspend character. You say you send SIGSTOP. That is most definitely going to stop your process. You have no say in the matter. SIGSTOP and SIGTSTP are two different signals. The first one cannot be caught, blocked or ignored. The second one is the stop signal generated from the keyboard. Do not mix them. Good luck. --Roberto ______________________________________________________________________________ || Internet: shirono@ssd.harris.com Roberto Shironoshita || Harris Corporation || ...!novavax---\ Computer Systems Division || UUCP: ...!uunet-------!hcx1!shirono || ...!mit-eddie-/ ------------------------------------------------------------------------------ DISCLAIMER: The opinions expressed here are my own; they in no way reflect the opinion or policies of Harris Corporation.
richard@aiai.ed.ac.uk (Richard Tobin) (03/02/89)
Does Unix make any guarantees about when a signal will be delivered? The man page for kill doesn't say anything about this in any of the versions at my disposal. In particular, if a process sends itself a signal, will it be handled before the kill system call returns? Looking at the man page actually confused me further. My manuals for 4.1BSD, 4.2BSD and SunOS4.0 claim that kill(0, sig) sends sig to all *other* processes in the process group (SunOS4.0 is particularly explicit about this). 4.3BSD and SunOS 3.2 just say all processes in the process group. Presumably the latter description is the correct one for all these systems? (Sixth edition refers to "all other processes which have the same controlling typewriter".) -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
rogerc@ncrcae.Columbia.NCR.COM (Roger Collins) (03/03/89)
In article <225@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: > Does Unix make any guarantees about when a signal will be delivered? Speaking only for System V... Once the kill system call has started it will not be pre-empted (as with any system call that does not sleep). The signal will be delivered as soon after that as hardware will allow (forget about interrupts). When it actually gets processed depends on the scheduler. > In particular, if a process sends itself a signal, will it be handled > before the kill system call returns? Yes, and no. The kernel's kill() function will have already completed. But just before the kernel jumps back to user mode after a sys call, it asks "Are there any signals to process?" If there are, the kernel handles them. That's why I say yes and no. From the application's point of view, it gets sent and processed all in the same command (kill). > Looking at the man page actually confused me further. My manuals for > 4.1BSD, 4.2BSD and SunOS4.0 claim that kill(0, sig) sends sig to all > *other* processes in the process group (SunOS4.0 is particularly > explicit about this). 4.3BSD and SunOS 3.2 just say all processes in > the process group. Presumably the latter description is the correct > one for all these systems? A cursory glance at System V source reveals the former is true. Kill(0, sig) sends sig to ALL processes in the process group including the calling process. -- Roger Collins NCR - E&M Columbia rogerc@ncrcae.Columbia.NCR.COM
rml@hpfcdc.HP.COM (Bob Lenk) (03/04/89)
> Does Unix make any guarantees about when a signal will be delivered? The > man page for kill doesn't say anything about this in any of the versions > at my disposal. In all implementations I know of a signal sent by a process to itself will be delivered before kill() returns, with one possible exception. If the process happens to receive some other signal that it is catching with exactly the right timing, it is possible that it will execute the signal handler for that other signal and then return from kill() without delivering the signal sent by kill(). This possibility exists in most non-reliable signal implementations (eg. V7, SVR2). It does not exist in 4.2 or 4.3. I'm not sure about 4.1 or SVR3 (with their variant of reliable signals). This is not mentioned in any manual I know of. POSIX (IEEE 1003.1) states: If the value of _pid_ causes _sig_ to be generated for the sending process, either _sig_ or at least one pending unblocked signal shall be delivered to the sending process before the kill() function returns. It also has similar wording for sigprocmask() (similar to sigsetmask() in 4.2/4.3 or sigrelse() in 4.1/SVR3). > Looking at the man page actually confused me further. My manuals for > 4.1BSD, 4.2BSD and SunOS4.0 claim that kill(0, sig) sends sig to all > *other* processes in the process group (SunOS4.0 is particularly > explicit about this). 4.3BSD and SunOS 3.2 just say all processes in > the process group. Presumably the latter description is the correct > one for all these systems? It appears to be correct for at least 4.2 and 4.3. For kill(-1, sig) the calling process is not sent the signal in these systems, but is sent the signal in System V. Much time was spent agonizing over that difference in POSIX deliberations, but no one ever questioned that kill(0, sig) goes to the whole pgrp including the sender (which POSIX requires). I'd never noticed that in the 4.2 manuals before. > (Sixth edition refers to "all other > processes which have the same controlling typewriter".) And furthermore makes the statement that "In no case is it possible for a process to kill itself". It's not clear if that is only supposed to refer to a pid of 0, or even to an explicit kill(getpid(), sig). I don't have V6 source handy. Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com
dclark@b11.ingr.com (Dave Clark) (02/20/91)
When debugging a program recently, I found that it was crashing due to receipt of a signal "SIGEMT." My manual describes this as: SIGEMT 07 EMT instruction Naturally, "EMT" is not defined anywhere else in the manual. Can someone out there in netland tell me what EMT stands for? (Emergency Medical Technician is possible, but I can't figure out how one could get into the computer.) -- ------------------------------------------------------------------------------ Dave Clark Phone: 205/730-5664 Intergraph Corp. UUCP: uunet!ingr!b11!dclark Huntsville, AL 35894-0001 Internet: dclark@b11.ingr.com
tim@proton.amd.com (Tim Olson) (02/21/91)
In article <1991Feb20.153845.14999@b11.ingr.com> dclark@b11.ingr.com (Dave Clark) writes: | | When debugging a program recently, I found that it was crashing due to receipt | of a signal "SIGEMT." My manual describes this as: | | SIGEMT 07 EMT instruction | | Naturally, "EMT" is not defined anywhere else in the manual. Can someone out | there in netland tell me what EMT stands for? On the PDP-11 processor, the EMT (Emulator Trap) instructions were opcodes 0104000 - 0104377 that simply caused a specific trap to occur when executed. They were presumably to be used for emulating other instructions not included in the standard instruction set. The UNIX kernel for the PDP-11 generated a SIGEMT signal when this trap occured. That's what the original "EMT" stands for, but what causes it in your system is a different matter (and subject to the actual implementation). It is often used as the signal generated for non-floating point arithmetic exceptions (e.g. overflow), since there usually is no other standard signal for these. For example, SunOS generates a SIGEMT when a taddcctv instruction (tagged add, set condition codes, trap overflow) overflows. -- -- Tim Olson Advanced Micro Devices (tim@amd.com)
gwyn@smoke.brl.mil (Doug Gwyn) (02/22/91)
In article <1991Feb20.153845.14999@b11.ingr.com> dclark@b11.ingr.com (Dave Clark) writes: >When debugging a program recently, I found that it was crashing due to receipt >of a signal "SIGEMT." My manual describes this as: > SIGEMT 07 EMT instruction >Naturally, "EMT" is not defined anywhere else in the manual. Can someone out >there in netland tell me what EMT stands for? (Emergency Medical Technician >is possible, but I can't figure out how one could get into the computer.) EMT is a PDP-11 instruction meaning "EMulator Trap", intended to be used to implement a form of system call and widely used for such in DEC's PDP-11 operating systems. (UNIX used the TRAP instruction instead.) While some signals may be synchronously generated upon occurrence of certain specific conditions during execution of a process, any signal number may be asynchronously sent to a process via the kill() system call. Therefore a SIGEMT need not always imply that a PDP-11 EMT instruction had been executed.
larry@st-andy.uucp (Larry Martell) (03/04/91)
In article <1991Feb20.153845.14999@b11.ingr.com> dclark@b11.ingr.com (Dave Clark) writes: > >When debugging a program recently, I found that it was crashing due to receipt >of a signal "SIGEMT." My manual describes this as: > > SIGEMT 07 EMT instruction > >Naturally, "EMT" is not defined anywhere else in the manual. Can someone out >there in netland tell me what EMT stands for? EMT stands for emulator trap. -- Larry Martell uunet!st-andy!larry 212-668-9478