11-15-2007
Quote:
some operating systems require the signal handler to be reinstalled after calling, eg
I doubt whether it is operating system dependent.
It is dependent on the semantics of the signal used, whether older semantics is used or the newer semantics.
Once the function registered for signal handler is executed, the function has to be re-registered again to ensure that the function is executed when a signal of same type is received again
This is not needed with newer semantics, no need for re-registering it again and again.
10 More Discussions You Might Find Interesting
1. Programming
I am trying to send a SIGUSR1 to a set of process. Please tell
me how to do. I've tried the system call raise(int sig) but it just
raise a signal of to the 'current process.'
My program is about a network chat server. When a client
connects in, The main process will fork a new process... (1 Reply)
Discussion started by: Namely
1 Replies
2. UNIX for Advanced & Expert Users
hi
I have created a application which uses SIGUSR2. It send this signal to server and waits for signal SIGUSR2 from server after server performing some operation server sends SIGUSR2 back to the application. The application then quits.
This works fine which ran from terminal , but when I... (3 Replies)
Discussion started by: khan_069
3 Replies
3. Programming
I am using the signal function, and passing it a function named quit procedure...I get the following warning....
passing arg2 of signal from incompatible pointer type...
void quit_procedure(void); //this is the way i define my prototype...
signal(SIGINT, quit_procedure);
Please guide... (5 Replies)
Discussion started by: jacques83
5 Replies
4. Programming
i wrote handler for sigsegv such that i can allocate memory for a variable to which
sigsegv generated for illlegal acces of memory.
my code is
#include <signal.h>
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
char *j;
void segv_handler(int dummy)
{
j=(char *)malloc(10);
... (4 Replies)
Discussion started by: pavan6754
4 Replies
5. Programming
hi friends i have a problem in signal handling ...
let me explain my problem clearly..
i have four process ..
main process forks two child process and each child process again forks another new process respectively...
the problem is whenever i kill the child process it is reforking and the... (2 Replies)
Discussion started by: senvenugopal
2 Replies
6. Shell Programming and Scripting
Hi everyone! I want to be able to send a signal to another machine on the same network, and have it trigger a script on that machine. Here's the reason why I can't just ssh: I don't have a username on that machine, but there is a user that is always logged on that I can do stuff on.
So, I want... (5 Replies)
Discussion started by: declannalced
5 Replies
7. Programming
Hi all,
Sorry about the title,at first i decided to ask a problem about the signal mechanism,however,i'm now figured it out.Sorry to forget modify the title:wall:.I had a small problem that if i use the code which is commented,the code would get a segment fault,while the above code NOT.what's... (4 Replies)
Discussion started by: homeboy
4 Replies
8. Programming
i m unble to execute code of
signal handler using
a) Wait b) Waitpid (1 Reply)
Discussion started by: madhura
1 Replies
9. Programming
I'm newbie in UNIX programming, I have a problem with signals. I'm writing multithread program, where threads can die at any moment. When thread dies it generates signal SIGUSR1 to main thread and then thread dies. Main thread gets a signal and waits for thread dead.
I wrote program like this:
... (5 Replies)
Discussion started by: DendyGamer
5 Replies
10. Linux
hey,
i have been facing a very fatel error with dovecot..
i am getting this error in my dovecot.log file
dovecot: Feb 13 15:21:02 Fatal: chdir(/var/mail/folders/user1) failed with uid 1001: Permission denied
dovecot: Feb 13 15:21:02 Error: child 18732 (imap) returned error 89
dovecot: Feb... (3 Replies)
Discussion started by: htshshrm2
3 Replies
LEARN ABOUT REDHAT
signal
SIGNAL(2) Linux Programmer's Manual SIGNAL(2)
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 to the signal (see signal(7)) occurs. Finally, if the han-
dler is set to a function sighandler then first either the handler is reset to SIG_DFL or an implementation-dependent blocking of the sig-
nal 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
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.
According to POSIX (3.3.1.3) it is unspecified what happens when SIGCHLD is set to SIG_IGN. Here the BSD and SYSV behaviours differ, caus-
ing BSD software that sets the action for SIGCHLD to SIG_IGN to fail on Linux.
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), kill(2), killpg(2), pause(2), raise(3), sigaction(2), signal(7), sigsetops(3), sigvec(2), alarm(2)
Linux 2.2 2000-04-28 SIGNAL(2)