Geek Answers Handbook

IPC using signals on Linux

Can IPC (inter process communication) be performed by signal capture and signal enhancement?

I made two programs. In the first program, I processed signals, and in another program, I just raised the signal that I want to process in another program. I work fine for me, but I want to communicate between the two programs using signals, and also want to send some bytes of data with this boost signal. How can i do this?

I want to send messages with this signal. Can I do it? Is it possible?

And also, what are the disadvantages and advantages of IPC signaling mechanisms?

Below is the working code of my two programs. With this, I can just pick up the signals and catch the signals, but I want to transfer data from one program to another.

In the second program, I used the first program process identifier. 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); } }
+4
source share
4 answers

Signals are designed to provide a rudimentary form of control over the process, and not as an IPC mechanism. Signals have several problems when used as anything else:

  • Many system calls will be interrupted by a signal and require special handling.

  • Accordingly, a lot of code in the wild is not safe for signals.

  • Signals do not contain any data content other than themselves. This makes them mostly useless as a messaging method.

  • You can do so much in the signal handler.

  • Most importantly, subsequent signals of the same type are not queued - they are combined into one instance.

  • More importantly, the signals are not transmitted in the same order in which they were created. On the manual page:

    In contrast, if several standard signals are expected for a process, the order in which they are delivered is unspecified .

You can theoretically be able to tune some channel using several signals going back and forth, and some act as some kind of confirmation, but not a single sane person wants to do something. Instead, you can use smoke alarms ...

+11
source

Is it possible to perform IPC (interprocess communication) using signal capture and signal enhancement?

Yes and no. Given only signals, you can send a signal to another process, but you cannot send anything but a signal.

I want to send messages with this signal. Can I do it? Is it possible?

No, not the way you try. You can use sockets, files, pipes, or named pipes for this. If you want to know more about UNIX IPC, read UNIX Advanced Programming .

+4
source

No, do not try to use signals for this. You cannot attach additional data using signals other than the siginfo structure. The main problem with using signals is that so little signal is safe. You need to avoid almost all C execution routines and make sure that the EINTR receiver program checks all of its kernel calls. The only thing you can say about when a signal arises is that it will not when you expect it (a bit like the Spanish Inquisition).

I suggest you explore other IPC mechanisms, such as shared memory, message queues, fifos (named pipes), and sockets.

+2
source

Except for one specific case that I came across, signals are usually not useful as an IPC mechanism.

The only time I used signals was part of the IPC mechanism when you need to interrupt the normal workflow of a signal process in order to process something, such as a timer interrupt. The signal (used signals along with extended shared memory to implement event management between processes. The shared memory contains a list of events that need to be processed, and the signal is used to process the process to process these events. These events are out-of-band and unpredictable, so the use of the signal was I did a lot of testing to test the implementation (and it was hard to get it stable).

This sigek along with the SIGRTMIN + 1 signal in Linux using glibc and using SA_RESTART in sigaction will eliminate the need to directly handle EINTR, see glibc: Primitives interrupted by signals . BSD has a similar scheme, so EINTR processing was not required on my system. All points made by other answers were reviewed and processed (and tested).

However, if you just want to pass values ​​back and forth as part of the normal operation of the process, then it is better to use another IPC, such as sockets, files, pipes, or named pipes. If you can use ZeroMQ , then even better, as it does a very difficult job for you in a very elegant way.

+1
source

More articles:


All Articles