lm@cottage.WISC.EDU (Larry McVoy) (07/02/87)
Does anyone know what the SIGSTOP signal is - it's not the keyboard (^Z) stop signal. So what's it there for? Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
ron@topaz.rutgers.edu (Ron Natalie) (07/02/87)
Programs that play around with the screen, use raw mode, or otherwise want to perform some action when the SIGTSTP (the one generated by ^Z) occurs use this. They catch the SIGTSTP signal and when they really want to stop themselves they send SIGSTOP to themselves. It's sort of analogous to SIGTERM and SIGKILL. -Ron
guy%gorodish@Sun.COM (Guy Harris) (07/03/87)
> Programs that play around with the screen, use raw mode, or otherwise > want to perform some action when the SIGTSTP (the one generated by ^Z) > occurs use this. They catch the SIGTSTP signal and when they really > want to stop themselves they send SIGSTOP to themselves. Except that a lot of them catch the SIGTSTP signal and, when they really want to stop themselves, they send SIGTSTP to themselves (after possibly resetting the signal action for SIGTSTP). Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
richl@penguin.USS.TEK.COM (Rick Lindsley) (07/03/87)
In article <3786@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: > Does anyone know what the SIGSTOP signal is - it's not the keyboard (^Z) stop > signal. So what's it there for? It's analogous to SIGKILL in that it can't be caught or ignored. That makes it handy when you may not want to kill a process, just stop it. One use of it: we had a user once who wanted to practice playing with fork(). So he wrote a simple C program ... basically "for (i=0;i<20;i++) while (fork()<0);" He thought this would create 20 processes. Of course it doesn't; it creates a LOT more. He quickly reached his process limit, thankfully, but killing one of these didn't do any good -- as soon as there was room, one of the forks would succeed and we'd be off to the races. There was one very easy solution, though -- SIGSTOP them all, THEN SIGKILL them all. (A second solution would be nice them all to 20 before killing them, though that's not as certain.) Another use for it would be stopping processes for backups on a "live" filesystem. We used to do that on one or two busy machines. The processes cannot ignore the signal, so you can essentially grind things to a halt without destroying context. Rick
lm@cottage.WISC.EDU (Larry McVoy) (07/03/87)
In article <13114@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: $ Programs that play around with the screen, use raw mode, or otherwise $ want to perform some action when the SIGTSTP (the one generated by ^Z) $ occurs use this. They catch the SIGTSTP signal and when they really $ want to stop themselves they send SIGSTOP to themselves. It's sort $ of analogous to SIGTERM and SIGKILL. Yeah, that's what I thought, but can't you do something like this: onstop() { /* put the terminal back into whatever is normal state */ normal(); signal(SIGTSTP, SIG_DFL); kill(getpid(), SIGTSTP); /* come back to here */ raw(); signal(SIGTSTP, onstop); return; } I had something like this working once - but it was a while ago. It doesn't work now and I think it might be because 4.3 does signals a little differently than the SysV/enhanced system I was working on. In particular, BSD blocks further signals while in the handler, right? So is that why the code above might not work? Surely you don't need two signals (on catchable, one not) for each "user" signal, do you? Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
cmf@cisunx.UUCP (Carl M. Fongheiser) (07/06/87)
SIGSTOP is a non-ignorable, non-catchable way of stopping a process, just as SIGKILL is a non-ignorable, non-catchable way of aborting a process. Carl Fongheiser Systems Analyst/Programmer University of Pittsburgh ...!pitt!cisunx!cmf cmf@pittvms.BITNET