I have a server and client codes that IPC with each other via named pipes(FIFO). Client sends SIGNAL(SIGUSR1 for example) to Server and checking to see if any signal arrived with given time resolution(via command line argument). Server checks (if its 5ms) 5ms everytime, checks if any signal arrived after 5ms , if arrived it does some code , if not continues until it catches a signal.
So here is that what my problem lies. I dont know what to use for these kind of action. I looked up "Unix Systems Programming: Communication, Concurrency, and Threads Kay A. Robbins , Steven Robbins" found some functions that might be use for me. Sleep,Alarm,uSleep,NanoSleep,Pause. But i dont know which one to use in my situation. Sleep is out of question i think due it takes seconds and i think it overflows when you try to convert to milliseconds.
A little code snippet or psudocode would be nice to understand for me.
I simply asking how to check if signal arrived in given resolution frequency. I have to check if signal arrived in those milliseconds. Check any given "n" mseconds if signal catched.
I think that the function nanosleep (and also usleep) could work!
You have to install a signal handler for the desired signal that can be catched by the program, e.g.:
#include <signal.h>
/* Handler for the signals */
void my_handler(int signum)
{
if(signum == SIGUSR1) {
/* Perform an action on signal SIGUSR1*/
}
}
int main(int argc, char * argv[]){
/* .... */
/* Install the signal handler to catch the desired signals*/
signal(SIGUSR1, my_handler);
/* .... */
}
You have to loop and wait for a signal. And if you catch a signal you have to perform the actions either inside the handler or using the exception that raise when nanosleep is interrupted.
#include <time.h> /* Contains nanosleep + timespec definition */
#include <errno.h> /* Contains the errno variable and the ERROR_CODE macros */
#include <stdio.h> /* Contains definition of perror */
#include <stdlib.h> /* Contains the exit function */
int main(int argc, char * argv[]){
/* fetch milliseconds from argv and put in a variable named "ms" */
struct timespec interval;
interval.tv_sec = 0; /* Seconds*/
interval.tv_nsec = ms*1e6; /* 10^6 Nanoseconds = 1 millisecond */
struct timespec interrupted;
/* .. */
while(1) {
if(nanosleep(&interval, &interrupted) != 0){
/* The sleeping was interrupted! */
if(errno == EINTR){
//The interruption is due to a signal
}
else {
/*The interruption is due to another cause (read the man page) --> Print an error message */
perror("Nanosleep");
break; /* Exit from main loop */
}
}
return EXIT_FAILURE;
}
Alternatively you can also deal the signals inside the handlers.
Alternative Solution
If you are sure that a signal will ever come and don't need to control each 5 milliseconds you could also use the function pause. In fact the man page says:
pause causes the calling process (or thread) to sleep until a signal
is delivered that either terminates the process or causes the
invocation of a signal-catching function.
In this case you have only to install the signal handler and wait.
Let me know if it answered your question.
Sincerly yours,
Mirko
Related
The APUE book says that: If the signal occurs after the test of sig_int_flag but before the call to pause, the process could go to sleep forever.
I don't know why, can somebody tells me?
Thanks a lot.
int sig_int(); /* my signal handling function */
int sig_int_flag; /* set nonzero when signal occurs */
int main() {
signal(SIGINT, sig_int) /* establish handler */
.
.
.
while (sig_int_flag == 0)
pause(); /* go to sleep, waiting for signal */
}
int sig_int() {
signal(SIGINT, sig_int); /* reestablish handler for next time */
sig_int_flag = 1; /* set flag for main loop to examine */
}
If an interrupt signal is issued at the precise time you're describing:
the flag has been checked false: entering loop
signal resets itself, setting the flag to 1, but too late (test has been done)
since loop has already been entered, pause() is called and the program waits
That said, if CTRL+C/SIGINT is triggered another time, you can exit the loop, so it's not that critical, since that signal can be issued manually.
If you want to check that behaviour, I suggest you add a sleep statement:
while (sig_int_flag == 0)
{
printf("Hit CTRL+C in the next 10 seconds to trigger the bug\n");
sleep(10);
pause(); /* go to sleep, waiting for signal */
}
A workaround would be to remove the pause() statement and replace it by a polling loop:
while (sig_int_flag == 0)
{
sleep(1);
}
If a SIGINT occurs anywhere in the loop, including between the while and the sleep, then the worse thing that can happen is that the program waits 1 second before noticing that the flag is set, then it exits the loop, and the other, more plausible case it that the sleep call is interrupted, and the loop is exited immediately, so when the signal is set, there's little visible difference between that and a pause call if we only expect SIGINT.
The question's already answered. However, additional answer can consolidate the idea.
while (sig_int_flag == 0) {
<----- think it signal is caught here before pause btw while and pause()
pause(); /* go to sleep, waiting for signal */
}
Having caught, signal handler runs. After it finishes its task, it returns to a point at which the signal is caught, in main() in this case. So, the point is pause() and pause() is called. It waits again SIGINT to catch. To exemplify it, I add sleep(5) equivalently to catch prior pause().
So, we typically want the second situation. To achieve it always, the aforementioned code block has to be atomic. That's why sigsuspend() is better and should be used.
If you would like to experience the fallible case,
#include <signal.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
volatile sig_atomic_t sig_int_flag = 0; /* set nonzero when signal occurs */
char const * handlerMsg = "in handler\n";
int handlerMsgLen;
void sig_int(int s) {
signal(SIGINT, sig_int); /* reestablish handler for next time */
sig_int_flag = 1; /* set flag for main loop to examine */
write(2, handlerMsg, handlerMsgLen);
}
void mySleep() {
for (int i = 0; i < 5; ++i) {
sleep(1);
fprintf(stderr, "%d ", i + 1);
}
}
int main() {
handlerMsgLen = strlen(handlerMsg);
signal(SIGINT, sig_int); /* establish handler */
while (sig_int_flag == 0) {
mySleep();
pause(); /* go to sleep, waiting for signal */
}
}
So I'm trying to call an alarm to display a message "still working.." every second.
I included signal.h.
Outside of my main I have my function: (I never declare/define s for int s)
void display_message(int s); //Function for alarm set up
void display_message(int s) {
printf("copyit: Still working...\n" );
alarm(1); //for every second
signal(SIGALRM, display_message);
}
Then, in my main
while(1)
{
signal(SIGALRM, display_message);
alarm(1); //Alarm signal every second.
That's in there as soon as the loop begins. But the program never outputs the 'still working...' message. What am I doing incorrectly? Thank you, ver much appreciated.
Signal handlers are not supposed to contain "business logic" or make library calls such as printf. See C11 ยง7.1.4/4 and its footnote:
Thus, a signal handler cannot, in general, call standard library functions.
All the signal handler should do is set a flag to be acted upon by non-interrupt code, and unblock a waiting system call. This program runs correctly and does not risk crashing, even if some I/O or other functionality were added:
#include <signal.h>
#include <stdio.h>
#include <stdbool.h>
#include <unistd.h>
volatile sig_atomic_t print_flag = false;
void handle_alarm( int sig ) {
print_flag = true;
}
int main() {
signal( SIGALRM, handle_alarm ); // Install handler first,
alarm( 1 ); // before scheduling it to be called.
for (;;) {
sleep( 5 ); // Pretend to do something. Could also be read() or select().
if ( print_flag ) {
printf( "Hello\n" );
print_flag = false;
alarm( 1 ); // Reschedule.
}
}
}
Move the calls to signal and alarm to just before your loop. Calling alarm over and over at high speed keeps resetting the alarm to be in one second from that point, so you never reach the end of that second!
For example:
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
void display_message(int s) {
printf("copyit: Still working...\n" );
alarm(1); //for every second
signal(SIGALRM, display_message);
}
int main(void) {
signal(SIGALRM, display_message);
alarm(1);
int n = 0;
while (1) {
++n;
}
return 0;
}
Do not call alarm() twice, just call it once in main() to initiate the callback, then once in display_message().
Try this code on Linux (Debian 7.8) :
#include <stdio.h>
#include <signal.h>
void display_message(int s); //Function for alarm set up
void display_message(int s)
{
printf("copyit: Still working...\n" );
alarm(1); //for every second
signal(SIGALRM, display_message);
}
int main()
{
signal(SIGALRM, display_message);
alarm(1); // Initial timeout setting
while (1)
{
pause();
}
}
The result will be the following one :
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
copyit: Still working...
The alarm() call is for a one off signal.
To repeat an alarm, you have to call alarm() again each time the signal occurs.
Another issue, also, is that you're likely to get EINTR errors. Many system functions get interrupted when you receive a signal. This makes for much more complicated programming since many of the OS functions are affected.
In any event, the correct way to wait for the next SIGALRM is to use the pause() function. Something the others have not mentioned (instead they have tight loops, ugly!)
That being said, what you are trying to do would be much easier with a simple sleep() call as in:
// print a message every second (simplified version)
for(;;)
{
printf("My Message\n");
sleep(1);
}
and such a loop could appear in a separate thread. Then you don't need a Unix signal to implement the feat.
Note: The sleep() function is actually implemented using the same timer as the alarm() and it is clearly mentioned that you should not mix both functions in the same code.
sleep(3) may be implemented using SIGALRM; mixing calls to alarm() and sleep(3) is a bad idea.
(From Linux man alarm)
void alarm_handler(int)
{
alarm(1); // recurring alarm
}
int main(int argc, char *argv[])
{
signal(SIGALRM, alarm_handler);
alarm(1);
for(;;)
{
printf("My Message\n");
// ...do other work here if needed...
pause();
}
// not reached (use Ctrl-C to exit)
return 0;
}
You can create variations. For example, if you want the first message to happen after 1 second instead of immediately, move the pause() before the printf().
The "other work" comment supposes that your other work does not take more than 1 second.
It is possible to get the alarm signal on a specific thread if work is required in parallel, however, this can be complicated if any other timers are required (i.e. you can't easily share the alarm() timer with other functions.)
P.S. as mentioned by others, doing your printf() inside the signal handler is not a good idea at all.
There is another version where the alarm() is reset inside main() and the first message appears after one second and the loop runs for 60 seconds (1 minute):
void alarm_handler(int)
{
}
int main(int argc, char *argv[])
{
signal(SIGALRM, alarm_handler);
for(int seconds(0); seconds < 60; ++seconds)
{
alarm(1);
// ...do other work here if needed...
pause();
printf("My Message\n");
}
// reached after 1 minute
return 0;
}
Note that with this method, the time when the message will be printed is going to be skewed. The time to print your message is added to the clock before you restart the alarm... so it is always going to be a little over 1 second between each call. The other loop is better in that respect but it still is skewed. For a perfect (much better) timer, the poll() function is much better as you can specify when to wake up next. poll() can be used just and only with a timer. My Snap library uses that capability (look for the run() function, near the bottom of the file). In 2019. I moved that one .cpp file to the eventdispatcher library. The run() function is in the communicator.cpp file.
POSIX permits certain of its functions to be called from signal handling context, the async-signal safe functions, search for "async-sgnal safe" here. (These may be understood as "system calls" rather than library calls). Notably, this includes write(2).
So you could do
void
display_message (int s) {
static char const working_message [] = "copyit: Still working...\n";
write (1, working_message, sizeof working_message - sizeof "");
alarm(1); /* for every second */
}
By the way, precise periodic alarms are better implemented using setitimer(2),
since these will not be subject to drift. Retriggering the alarm via software, as done here, will unavoidably accumulate error over time because of the time spent executing the software as well as scheduling latencies.
In POSIX sigaction(2) superceedes signal(2) for good reason:
the original Unix signal handling model was simple. In particular,
a signal handler was reset to its original "deposition" (e.g., terminate
the process) once it was fired. You would have to re-associate
SIGALRM with display_message() by calling signal() just before
calling alarm() in display_message().
An even more important reason for using sigaction(2) is the
SA_RESTART flag. Normally, system calls are interrupted when
a signal handler is invoked. I.e., when then signal handler returns,
the system call returns an error indication (often -1) and errno is
set to EINTR, interrupted system call. (One reason for this
is to be able to use SIGALRM to effect time outs, another is
to have a higher instance, such as a user, to "unblock" the
current process by sending it a signal, e.g.,
SIGINT by pressing control-C at the terminal).
In your case, you want signal handling to be transparent
to the rest of the code, so you would set the SA_RESTART flag
when invoking sigaction(2). This means the kernel should
restart the interrupted system call automatically.
ooga is correct that you keep reloading the alarm so that it will never go off. This works. I just put a sleep in here so you don't keep stepping on yourself in the loop but you might want to substitute something more useful depending on where you are headed with this.
void display_message(int s)
{
printf("copyit: Still working...\n" );
// alarm(1); //for every second
// signal(SIGALRM, display_message);
}
int main(int argc, char *argv[])
{
int ret;
while(1)
{
signal(SIGALRM, display_message);
alarm(1);
if ((ret = sleep(3)) != 0)
{
printf("sleep was interrupted by SIGALRM\n");
}
}
return (0);
}
I have a question about handling a signal.
Assume that if we recieve SIGINT signal, we should print "Recieved Signal". If within ten seconds the handler recieves another signal, it should print "Shutting Down" then exit with status 1.
I made my code like this:
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
void handler(int);
void secondhandler(int);
void alrmhandler(int);
void alrmhandler (int alrmsig)
{
alarm(0);
}
void secondhandler(int sig)
{
/* after recieving second signal prints shutting down and exit */
printf("Shutting Down\n");
exit(1);
}
void handler ( int sig )
{
/* recieve first SIGINT signal */
printf ("Recieved Signal\n");
/* handle for the alarm function */
signal(SIGALRM, alrmhandler);
/* start 10s alarm */
alarm(10);
/* catch second SIGINT signal within 10s*/
signal(SIGINT, secondhandler);
}
int main( void )
{
signal(SIGINT, handler);
printf( "Hello World!\n" );
for ( ;; )
{
/* infinite loop */
}
return 0;
}
I tried to compile it with dev c++, but it failed. Because SIGALRM undeclared(first use in this function).
Anyway, what I want to know is if this code is right. I actually kinda not sure with the alrmhandler(). should I ignore the SIGALRM?
If you are on a Windows platform, the only signals you will be able to send are : SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, or SIGTERM.
You write:
what I want to know is if this code is right.
Not entirely. printf() is not async-signal-safe, and so should not be called from within a signal handler unless you are very sure it is safe to do so. It is not safe to do so within the code you provide.
The alarm() technique is, generally, race-prone. Your ten second alarm might expire in the middle of your secondhandler() function. To guard against this, you might mask out signals to compensate with a more sophisticated signal manipulation function.
There are more elegant/flexible ways of implementing the timeout you desire, but that's perhaps a question better suited for codereview.stackexchange.com.
i have written a small piece of code. This code first blocks the {SIGSEGV}, then adds SIGRTMIN to the same set. So, my final signal set is, {SIGSEGV,SIGRTMIN}. Thus, if i use SIG_UNBLOCK, as per my understanding, first SIGRTMIN should be unblocked, and then again if i invoke SIG_UNBLOCK, SIGSEGV should be unblocked.
That is, 1) {SIGSEGV,SIGRTMIN} 2) SIG_UNBLOCK = unblock SIGRTMIN, 3) Again invoke SIG_UNBLOCK = unblock SIGSEGV.
I am giving the process a SIGRTMIN only, thus my second unblock should halt the process with SIGRTMIN. But it is not. Please help.
N.B: Please don't give links to answers of other questions on sigprocmask( ), i have seen them and they don't clarify my question.
enter code here
#include <signal.h>
#include <unistd.h>
#include <stdio.h>
int main()
{
sigset_t old_set,new_set;
sigemptyset(&old_set);
sigemptyset(&new_set);
if(sigaddset(&old_set,SIGSEGV)==0)
{
printf("sigaddset successfully added for SIGSEGV\n");
}
sigprocmask(SIG_BLOCK,&old_set,NULL); // SIGSEGV signal is masked
kill(0,SIGSEGV);
//*****************************************************************
if(sigaddset(&new_set,SIGRTMIN)==0)
{
printf("sigaddset successfully added for SIGRTMIN\n");
}
sigprocmask(SIG_BLOCK,&new_set,&old_set); // SIGRTMIN signal is masked
kill(0,SIGSEGV);
//****************** Unblock one signal at a time ******************
sigprocmask(SIG_UNBLOCK,&new_set,&old_set); // SIGRTMIN signal is unmasked
sigprocmask(SIG_UNBLOCK,&new_set,&old_set); // SIGSEGV signal is unmasked
}
Output:
[root#dhcppc0 signals]# ./a.out
sigaddset successfully added for SIGSEGV
sigaddset successfully added for SIGRTMIN
(Note:SIGSEGV is not received even after sigprocmask(SIG_UNBLOCK,&new_set,&old_set); a second time)
Your premise is wrong. The whole set gets blocked and unblocked with a single call of sigprocmask.
Also, normally you would create a set containing every signal you want to block, then you would attempt to block them all with sigprocmask(SIG_BLOCK, pointer_to_sigset);.
Your code doesn't really unblock SIGSEGV though. Here's what i would write WITHOUT error handling, because it would make the snippet unnecessarily long. Check every function
for errors though, the lists of possible errors are provided by man pages:
/* ... */
sigset_t signal_set; /* We don't need oldset in this program. You can add it,
but it's best to use different sigsets for the second
and third argument of sigprocmask. */
sigemptyset(&signal_set);
sigaddset(&signal_set, SIGSEGV);
sigaddset(&signal_set, SIGRTMIN);
/* now signal_set == {SIGSEGV, SIGRTMIN} */
sigprocmask(SIG_BLOCK, &signal_set, NULL): /* As i said, we don't bother with the
oldset argument. */
kill(0,SIGSEGV);
kill(0,SIGSEGV); /* SIGSEGV is not a realtime signal, so we can send it twice, but
it will be recieved just once */
sigprocmask(SIG_UNBLOCK, &signal_set, NULL); /* Again, don't bother with oldset */
/* SIGSEGV will be received here */
Of course, you might want to split blocking the signals into two operations on separate sets. The mechanism works like this: there is some set of blocked signals, which would replace oldset if you provided an oldset argument. You can add to that set with SIG_BLOCK, remove from that set with SIG_UNBLOCK, and change the whole set to your liking with SIG_SETMASK arguments of the sigprocmask function.
As kubi pointed out: Here is the modified code, problem is that, i messed up with old_set and new_set. The SIGSEGV was added in old_set, which was not unblocked, and hence i did not receive Segmentation fault (SIGSEGV signal).
Thanks to kubi.
enter code here
#include <signal.h>
#include <unistd.h>
#include <stdio.h>
int main()
{
sigset_t old_set,new_set;
sigemptyset(&old_set);
sigemptyset(&new_set);
if(sigaddset(&old_set,SIGSEGV)==0)
{
printf("sigaddset successfully added for SIGSEGV\n");
}
sigprocmask(SIG_BLOCK,&new_set,&old_set); // SIGSEGV signal is masked
kill(0,SIGSEGV);
//*****************************************************************
if(sigaddset(&new_set,SIGRTMIN)==0)
{
printf("sigaddset successfully added for SIGRTMIN\n");
}
if(sigprocmask(SIG_BLOCK,&new_set,&old_set)==-1) // SIGRTMIN signal is masked
{
perror("sigprocmask");
}
kill(0,SIGSEGV);
//****************** Unblock all signals ******************
if(sigprocmask(SIG_UNBLOCK,&new_set,&old_set)==-1) // SIGRTMIN signal is unmasked
{
perror("sigprocmask");
}
}
Basically,expected output of is that it catches KeyboardInterrupt 5 times and exits the 6th time.(If 1st line of handler() is un-commented)
Now, if i comment that line too, then
also the behavior of program doesnt
change even though I am using
unreliable API.
As I have used signal() function, this is unreliable bcos after the first call to the handler(), SIGINT will then have the default behavior, thats is of exiting the a.out..
The program still quits after 5 ^C.. WHY?
**
The code works even without
reinstating the handler(). WHy?
**
/* ursig1.c */
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
static int count = 0;
void handler(int signo) {
// signal(SIGINT,handler);
/* Re-instate handler */
++count;
/* Increment count */
write(1,"Got SIGINT\n",11); /* Write message */
}
int
main(int argc,char **argv) {
signal(SIGINT,handler);
/* Register function */
while ( count < 5 ) {
puts("Waiting for SIGINT..");
sleep(4);
/* Snooze */
}
puts("End.");
return 0;
}
Have a read of the Linux man page for signal(2), under the section Portability, where it discusses the varying behaviour of signal(2) across the many different versions of Unix. In particular,
In the original Unix systems, when a
handler that was established using
signal() was invoked by the
delivery of a signal, the disposition
of the signal would be reset to
SIG_DFL, and the system did not
block delivery of further instances
of the signal. System V also provides
these semantics for signal().
This is the behaviour you are expecting, but it is not what Linux provides, as allowed by POSIX.1. You should be using sigaction(2) to install your signal handlers to get portable and defined behaviour.