|
Home > Archive > Unix Programming > March 2005 > Question on SIGSTOP
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Question on SIGSTOP
|
|
|
| ****o,
What is the the behaviour of "overloading" the SIGSTOP? When I try to
provide a handler for it using signal, I get SIG_ERR. However bash, csh
and other s****s seem to be able to provide handlers for SIGSTOP for
when I press "Ctrl+Z" or when I do "kill -SIGSTOP process_id" I get a
"STOPPED message".
TIA
--
Imanpreet Singh Arora
PS. The website http://basicbash.activeventure.net/sect_12_01.html
says that Ctrl+Z sends SIGTSTP rather than SIGSTOP. Is this correct?
| |
| junky_fellow@yahoo.co.in 2005-03-30, 2:50 am |
|
Minti wrote:
> ****o,
>
> What is the the behaviour of "overloading" the SIGSTOP? When I try
to
> provide a handler for it using signal, I get SIG_ERR. However bash,
csh
> and other s****s seem to be able to provide handlers for SIGSTOP for
> when I press "Ctrl+Z" or when I do "kill -SIGSTOP process_id" I get a
> "STOPPED message".
>
> TIA
>
>
> --
> Imanpreet Singh Arora
> PS. The website http://basicbash.activeventure.net/sect_12_01.html
> says that Ctrl+Z sends SIGTSTP rather than SIGSTOP. Is this correct?
The signal SIGSTOP cannot be caught or ignored. So, you cannot provide
a handler for this. The SIGSTOP will always stop the process to which
it
is posted.
The SIGTSTP is an interactive stop signal. It can be handled and
ignored.
Your program should handle this signal if you have a special need to
leave
files or system tables in a secure state when a process is stopped. For
example, programs that turn off echoing should handle SIGTSTP so they
can
turn echoing back on before stopping.
| |
| Richard Kettlewell 2005-03-30, 7:55 am |
| "Minti" <imanpreet@gmail.com> writes:
> What is the the behaviour of "overloading" the SIGSTOP? When I try
> to provide a handler for it using signal, I get SIG_ERR.
You cannot provide a handler for SIGSTOP.
> However bash, csh and other s****s seem to be able to provide
> handlers for SIGSTOP for when I press "Ctrl+Z" or when I do "kill
> -SIGSTOP process_id" I get a "STOPPED message".
The message comes from the parent shell, not the suspended process.
It is the subprocess, not the shell, that receives the stop signal.
--
http://www.greenend.org.uk/rjk/
| |
|
|
Richard Kettlewell wrote:
> "Minti" <imanpreet@gmail.com> writes:
>
> You cannot provide a handler for SIGSTOP.
>
>
> The message comes from the parent s****, not the suspended process.
> It is the subprocess, not the s****, that receives the stop signal.
I would have understood this if it were to print "STOPPED" message only
for "Ctrl+Z", for it is only the s**** that sends the signal. But what
I am confused about is that why does this happen when I _specifically_
send SIGSTOP using kill. S****, be it parent or subprocess has no way
of providing a handler for SIGSTOP, so how does it get to know about
SIGSTOP signal.
| |
|
| Minti wrote:
> Richard Kettlewell wrote:
>
> I would have understood this if it were to print "STOPPED" message only
> for "Ctrl+Z", for it is only the s**** that sends the signal. But what
> I am confused about is that why does this happen when I _specifically_
> send SIGSTOP using kill. S****, be it parent or subprocess has no way
> of providing a handler for SIGSTOP, so how does it get to know about
> SIGSTOP signal.
>
It is not the shell, but the child process
that is stopped.
The shell gets this status change via one of the wait() systemcalls.
man 2 wait will give you the details (lots of them!)
HTH,
AvK
| |
| Barry Margolin 2005-03-30, 7:23 pm |
| In article <1112212957.827926.3290@o13g2000cwo.googlegroups.com>,
"Minti" <imanpreet@gmail.com> wrote:
> Richard Kettlewell wrote:
>
>
> I would have understood this if it were to print "STOPPED" message only
> for "Ctrl+Z", for it is only the s**** that sends the signal. But what
> I am confused about is that why does this happen when I _specifically_
> send SIGSTOP using kill. S****, be it parent or subprocess has no way
> of providing a handler for SIGSTOP, so how does it get to know about
> SIGSTOP signal.
When a child process is stopped, the parent process is sent a SIGCHLD
signal. This signal can be caught, and the shell's handler then calls
one of the wait() variants, discovers that the child was stopped, and
prints the "STOPPED" message.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Richard Kettlewell 2005-03-31, 8:12 am |
| "Minti" <imanpreet@gmail.com> writes:
> Richard Kettlewell wrote:
>
> I would have understood this if it were to print "STOPPED" message
> only for "Ctrl+Z", for it is only the s**** that sends the signal.
> But what I am confused about is that why does this happen when I
> _specifically_ send SIGSTOP using kill. S****, be it parent or
> subprocess has no way of providing a handler for SIGSTOP, so how
> does it get to know about SIGSTOP signal.
Forget about signal handlers, they are not the issue here. The shell
calls waitpid() (or one of the related functions), which tells it why
the subprocess stopped.
(Why on earth are you starring out "shell"??)
--
http://www.greenend.org.uk/rjk/
| |
| Måns Rullgård 2005-03-31, 8:12 am |
| Richard Kettlewell <rjk@greenend.org.uk> writes:
> (Why on earth are you starring out "shell"??)
I guess someone's pattern matching is a bit too aggressive.
--
Måns Rullgård
mru@inprovide.com
| |
|
| Richard Kettlewell wrote:
> "Minti" <imanpreet@gmail.com> writes:
>
process.[vbcol=seagreen]
signal.[vbcol=seagreen]
>
> Forget about signal handlers, they are not the issue here. The shell
> calls waitpid() (or one of the related functions), which tells it why
> the subprocess stopped.
>
> (Why on earth are you starring out "shell"??)
I am myself suprised by it, all I am doing is copying pasting text
from my text editor onto google post, dunno where the problem is.
Anybody else having this problem.
Testing shell, shell, shell.
| |
| Barry Margolin 2005-03-31, 6:21 pm |
| In article <1112294723.810624.140770@o13g2000cwo.googlegroups.com>,
"Minti" <imanpreet@gmail.com> wrote:
> Richard Kettlewell wrote:
> process.
> signal.
>
> I am myself suprised by it, all I am doing is copying pasting text
> from my text editor onto google post, dunno where the problem is.
> Anybody else having this problem.
>
> Testing shell, shell, shell.
It's getting through now. But it looks like something you were using
earlier was getting rid of dirty words, like "hell". 
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
|
|
|
|
|