IPC using Signals on linux - c

Question

It is possible to do IPC (inter process communication) using signal catch and signal raise?
I made two programs. In the first program I did handling of signals, and in the other program I just raised signal which I want to handle in another program. I'ts working fine for me but I want to do communication between these two programs using signals and also want to send some bytes of data with this raise signal. How can I do this?
I want to pass messages with this signal also. Can i do it? It is possible?
And also, what are the disadvantages and advantages of IPC mechanisms using signals?
The following is working code of my two programs. Ising this, I am able to just raise signals and catch signals, but I want to pass data from one program to another.
In the second program, I used the first program's process ID. How can I make it dynamic.?
first program :
/* Example of using sigaction() to setup a signal handler with 3 arguments
* including siginfo_t.
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <string.h>
static void hdl (int sig, siginfo_t *siginfo, void *context)
{
printf("sig no = %d \n", sig);
if(sig == SIGINT)
exit(0);
printf ("Sending PID: %ld, UID: %ld\n",
(long)siginfo->si_pid, (long)siginfo->si_uid);
}
int main (int argc, char *argv[])
{
struct sigaction act;
sigemptyset(&act.sa_mask);
act.sa_sigaction = &hdl;
act.sa_flags = SA_SIGINFO;
if (sigaction(SIGUSR1, &act, NULL) < 0) {
perror ("sigaction SIGUSR1");
return 1;
}
if (sigaction(SIGINT, &act, NULL) < 0) {
perror ("sigaction SIGINT");
return 1;
}
while (1)
{
sleep(1);
}
return 0;
}
second program
#include <stdio.h>
#include <signal.h>
void main(void)
{
while (1)
{
sleep(1);
kill(11558, SIGUSR1);
}
}

Answer 1

Signals are intended to provide a rudimentary form of control over a process, not as an IPC mechanism. Signals have several issues when used as anything else:
A lot of system calls will be interrupted by a signal and need special handling.
Accordingly, a lot of code in the wild is not signal-safe.
Signals do not have any kind of data content, except for themselves. This makes them mostly useless as a message passing method.
There is only so much you can do in a signal handler.
Most importantly, subsequent signals of the same type are not queued - they are merged into one instance.
Even more important, there is no guarantee that signals are delivered in the same order as they were generated. From the manual page:
By contrast, if multiple standard signals are pending for a process, the order in which
they are delivered is unspecified.
You might theoretically be able set up some kind of channel using several signals going back and forth, with some acting like some sort of acknowledgement, but no sane person would want to attempt something like that. You might as well use smoke signals instead...

Answer 2

No, don't try and use signals for this. You cannot attach extra data with signals other than the siginfo struct. The main problem with using signals though is that so little is signal safe. You have to avoid just about all the C runtime routines, and make sure the recieving program does EINTR checks on all its kernel calls. The only thing you can say about when a signal occurs is that it won't be when you expect it (a bit like the Spanish Inquisition).
I suggest you look into the other IPC mechanisms, such as shared memory, message queues, fifos (named pipes), and sockets.

Answer 3

It is possible to do IPC (inter process communication) using signal catch and signal raise?
Yes and no. Considering signals only, you can send a signal to another process, but you can't send anything other than just a signal.
I want to pass messages with this signal also. Can i do it? It is possible?
No, not the way you're trying to. You can use sockets, files, pipes, or named pipes to do this. If you want to learn more about UNIX IPC, read Advanced Programming in the UNIX Environment.

Answer 4

Except in one specific case that I've encountered signals aren't generally useful as IPC mechanism.
The only time I've used signals was as part of an IPC mechanism when you need to interrupt the normal flow of operation of the signalled process to handle something, for example a timer interrupt. The signal ( have used signals together with boost shared memory to implement interprocess event management. The shared memory contains a list of events that need processing and the signal is used to get the process to process these events. These events are out-of-band and unpredictable so using a signal was ideal. I performed considerable testing to verify the implementation (and it was hard to get it all stable).
This used sigqueue together with signal SIGRTMIN+1 in a Linux environment using glibc and using SA_RESTART on the sigaction will avoid the need to directly handle EINTR see glibc: Primitives Interrupted by Signals. BSD has a similar scheme so EINTR handling wasn't required in my system. All of the points made by the other answers were considered and handled (and tested).
However if you just want to pass values back and forwards within the normal operation of the process then another IPC such as sockets, files, pipes or named pipes are better. If you can use ZeroMQ then even better as that does a lot of the hard work for you in a very elegant way.

Answer 5

I'm currently reading man 7 signal:
Real-time signals are distinguished by the following:
If the signal is sent using sigqueue(3), an accompanying value (either an integer or a pointer) can be sent with the signal. ...
Note: Real-time signals start from SIGRTMIN to SIGRTMAX.