IPC using Signals on linux

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.