user-0 提问: signal(),while(1).我不明白为什么：被注释的语句和它上面的语句会产生一样的输出结果

回复:
user: user-1
content: SIGNAL Section: Linux Programmer's Manual (2) Updated: 2000-04-28  --------------------------------------------------------------------------------    NAME signal - ANSI C signal handling    SYNOPSIS #include <signal.h>  typedef void (*sighandler_t)(int);   sighandler_t signal(int signum, sighandler_t handler);     DESCRIPTION The signal() system call installs a new signal handler for the signal with number signum. The signal handler is set to sighandler which may be a user specified function, or either SIG_IGN or SIG_DFL.  Upon arrival of a signal with number signum the following happens. If the corresponding handler is set to SIG_IGN, then the signal is ignored. If the handler is set to SIG_DFL, then the default action associated with the signal (see signal(7)) occurs. Finally, if the handler is set to a function sighandler then first either the handler is reset to SIG_DFL or an implementation-dependent blocking of the signal is performed and next sighandler is called with argument signum.   Using a signal handler function for a signal is called "catching the signal". The signals SIGKILL and SIGSTOP cannot be caught or ignored.       RETURN VALUE The signal() function returns the previous value of the signal handler, or SIG_ERR on error.      PORTABILITY The original Unix signal() would reset the handler to SIG_DFL, and System V (and the Linux kernel and libc4,5) does the same. On the other hand, BSD does not reset the handler, but blocks new instances of this signal from occurring during a call of the handler. The glibc2 library follows the BSD behaviour.  If one on a libc5 system includes <bsd/signal.h> instead of <signal.h> then signal is redefined as __bsd_signal and signal has the BSD semantics. This is not recommended.   If one on a glibc2 system defines a feature test macro such as _XOPEN_SOURCE or uses a separate sysv_signal function, one obtains classical behaviour. This is not recommended.   Trying to change the semantics of this call using defines and includes is not a good idea. It is better to avoid signal altogether, and use sigaction(2) instead.       NOTES The effects of this call in a multi-threaded process are unspecified.  The routine handler must be very careful, since processing elsewhere was interrupted at some arbitrary point. POSIX has the concept of "safe function". If a signal interrupts an unsafe function, and handler calls an unsafe function, then the behavior is undefined. Safe functions are listed explicitly in the various standards. The POSIX 1003.1-2003 list is   _Exit() _exit() abort() accept() access() aio_error() aio_return() aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed() cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect() creat() dup() dup2() execle() execve() fchmod() fchown() fcntl() fdatasync() fork() fpathconf() fstat() fsync() ftruncate() getegid() geteuid() getgid() getgroups() getpeername() getpgrp() getpid() getppid() getsockname() getsockopt() getuid() kill() link() listen() lseek() lstat() mkdir() mkfifo() open() pathconf() pause() pipe() poll() posix_trace_event() pselect() raise() read() readlink() recv() recvfrom() recvmsg() rename() rmdir() select() sem_post() send() sendmsg() sendto() setgid() setpgid() setsid() setsockopt() setuid() shutdown() sigaction() sigaddset() sigdelset() sigemptyset() sigfillset() sigismember() signal() sigpause() sigpending() sigprocmask() sigqueue() sigset() sigsuspend() sleep() socket() socketpair() stat() symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr() tcgetpgrp() tcsendbreak() tcsetattr() tcsetpgrp() time() timer_getoverrun() timer_gettime() timer_settime() times() umask() uname() unlink() utime() wait() waitpid() write().   According to POSIX, the behaviour of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by the kill(2) or the raise(3) functions. Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal. (Also dividing the most negative integer by -1 may generate SIGFPE.) Ignoring this signal might lead to an endless loop.   See sigaction(2) for details on what happens when SIGCHLD is set to SIG_IGN.   The use of sighandler_t is a GNU extension. Various versions of libc predefine this type; libc4 and libc5 define SignalHandler, glibc defines sig_t and, when _GNU_SOURCE is defined, also sighandler_t.     CONFORMING TO ANSI C      SEE ALSO kill(1), alarm(2), kill(2), pause(2), sigaction(2), sigqueue(2), sigvec(2), killpg(3), raise(3), sigsetops(3), signal(7)  --------------------------------------------------------------------------------

user: user-0
content: 引用 1 楼 zhao4zhong1 的回复:SIGNAL Section: Linux Programmer's Manual (2) Updated: 2000-04-28  --------------------------------------------------------------------------------    NAME signal - ANSI C signal handling    SYNOPSIS #include <signal.h>  typedef void (*sighandler_t)(int);   sighandler_t signal(int signum, sighandler_t handler);     DESCRIPTION The signal() system call installs a new signal handler for the signal with number signum. The signal handler is set to sighandler which may be a user specified function, or either SIG_IGN or SIG_DFL.  Upon arrival of a signal with number signum the following happens. If the corresponding handler is set to SIG_IGN, then the signal is ignored. If the handler is set to SIG_DFL, then the default action associated with the signal (see signal(7)) occurs. Finally, if the handler is set to a function sighandler then first either the handler is reset to SIG_DFL or an implementation-dependent blocking of the signal is performed and next sighandler is called with argument signum.   Using a signal handler function for a signal is called "catching the signal". The signals SIGKILL and SIGSTOP cannot be caught or ignored.       RETURN VALUE The signal() function returns the previous value of the signal handler, or SIG_ERR on error.      PORTABILITY The original Unix signal() would reset the handler to SIG_DFL, and System V (and the Linux kernel and libc4,5) does the same. On the other hand, BSD does not reset the handler, but blocks new instances of this signal from occurring during a call of the handler. The glibc2 library follows the BSD behaviour.  If one on a libc5 system includes <bsd/signal.h> instead of <signal.h> then signal is redefined as __bsd_signal and signal has the BSD semantics. This is not recommended.   If one on a glibc2 system defines a feature test macro such as _XOPEN_SOURCE or uses a separate sysv_signal function, one obtains classical behaviour. This is not recommended.   Trying to change the semantics of this call using defines and includes is not a good idea. It is better to avoid signal altogether, and use sigaction(2) instead.       NOTES The effects of this call in a multi-threaded process are unspecified.  The routine handler must be very careful, since processing elsewhere was interrupted at some arbitrary point. POSIX has the concept of "safe function". If a signal interrupts an unsafe function, and handler calls an unsafe function, then the behavior is undefined. Safe functions are listed explicitly in the various standards. The POSIX 1003.1-2003 list is   _Exit() _exit() abort() accept() access() aio_error() aio_return() aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed() cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect() creat() dup() dup2() execle() execve() fchmod() fchown() fcntl() fdatasync() fork() fpathconf() fstat() fsync() ftruncate() getegid() geteuid() getgid() getgroups() getpeername() getpgrp() getpid() getppid() getsockname() getsockopt() getuid() kill() link() listen() lseek() lstat() mkdir() mkfifo() open() pathconf() pause() pipe() poll() posix_trace_event() pselect() raise() read() readlink() recv() recvfrom() recvmsg() rename() rmdir() select() sem_post() send() sendmsg() sendto() setgid() setpgid() setsid() setsockopt() setuid() shutdown() sigaction() sigaddset() sigdelset() sigemptyset() sigfillset() sigismember() signal() sigpause() sigpending() sigprocmask() sigqueue() sigset() sigsuspend() sleep() socket() socketpair() stat() symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr() tcgetpgrp() tcsendbreak() tcsetattr() tcsetpgrp() time() timer_getoverrun() timer_gettime() timer_settime() times() umask() uname() unlink() utime() wait() waitpid() write().   According to POSIX, the behaviour of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by the kill(2) or the raise(3) functions. Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal. (Also dividing the most negative integer by -1 may generate SIGFPE.) Ignoring this signal might lead to an endless loop.   See sigaction(2) for details on what happens when SIGCHLD is set to SIG_IGN.   The use of sighandler_t is a GNU extension. Various versions of libc predefine this type; libc4 and libc5 define SignalHandler, glibc defines sig_t and, when _GNU_SOURCE is defined, also sighandler_t.     CONFORMING TO ANSI C      SEE ALSO kill(1), alarm(2), kill(2), pause(2), sigaction(2), sigqueue(2), sigvec(2), killpg(3), raise(3), sigsetops(3), signal(7)  -------------------------------------------------------------------------------- 1.按照逻辑，似乎程序A应该一直停留在while()语句中，是不可能有机会再次执行到语句：if()，也就没有可能使用signal()函数捕获信号并发送至sig_usr()处理了。 2.然而，程序A是可以捕获信号:SIGINT，并将其发送到sig_usr()函数处理   那么问题就是：为什么程序A可以执行到语句if()

user: user-0
content: 1.按照逻辑，似乎程序A应该一直停留在while()语句中，是不可能有机会再次执行到语句：if()，也就没有可能使用signal()函数捕获信号并发送至sig_usr()处理了。 2.然而，程序A是可以捕获信号:SIGINT，并将其发送到sig_usr()函数处理   那么问题就是：为什么程序A可以执行到语句if()