pardo@june.cs.washington.edu (David Keppel) (06/07/88)
[ Sorry if this has been around recently ]
[ Please REPLY by mail, I will summarize ]
I'm confused about signals, signal handlers, signal stacks, and
trampoline code. I've been told a bunch of different things (often
quite authoratatively :-) about how various versions of Un*x do it,
and some of the descriptions disagree with some of the other
descriptions. I'd like to know how this gets done on each of "your
favorite" version of Un*x, including BSD 4.3, 4.2, SysV, SunOS, Ultrix
(presumed like 4.2), Xenix, ...
Here is my (mis)understanding of what happens on 4.3BSD; please don't
think that I believe this to be the one true way, rather I want to
know where this isn't true.
+ Kernel decides to deliver a signal.
+ The kernel pushes a few instructions, called _trampoline_code_ on to
the stack.
+ The kernel transfers control to the trampoline code.
+ The trampoline code invokes the signal handler.
+ The call frame for the signal handler is pushed onto a seperate
(seperate from the standard stack) "signal stack".
+ The signal hander executes.
+ The signal handler returns, restoring the normal sp, fp, ap, ...
At the same time, the pc is set to the return point in the
trampoline code.
+ The trampoline code traps to the kernel.
+ The kernel cleans the trampoline code off of the stack.
This seems pretty wierd to me. Can somebody illuminate?
(E-mail, please. Advance thanks!)
;-D on ( coming soon to a signal stack near you ) Pardo
pardo@cs.washington.edu pardo@june.cs.washington.edu
...!{rutgers,cornell,ucsd,ubc-cs,textronix}!uw-june!pardorbj@icst-cmr.arpa (Root Boy Jim) (06/09/88)
Repeat after me: We all live in a signal trampoline... (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (04/15/89)
Under SYS V SIGCLD has special behaviour depending on what you pass to the
signal system call.
Specifically if SIG_IGN is used a parent process calling wait() will block
until all child processes die, and child processes will not become zombies
when the exit.
If SIG_DFL is used the parent process will proceed from a wait() after any
child process terminates and child processes will become zombies until the
parent process excutes a wait.
The question is:
If there are child processes in the zombie state when signal(SIGCLD,
SIG_IGN) is executed will they be terminated?
For example in the following code fragment is there a race condition between
the wait() call and the following signal(SIGCLD,SIG_IGN) call?
while (1) {
while(findajob()) {
if (cantfindslot()) {
signal(SIGCLD,SIG_DFL);
wait(&rc); /* race here */
signal(SIGCLD,SIG_IGN); /* race here */
}
startthejob();
}
sleep(30);
}
It seems to be ok. Can anyone who has seen the inner workings of signal()
comment?
--
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
--
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)