Question

To work with databases or files as simple data persistance layer is easy to understand. But there are also ways to use them as communication channel to transfer data from one running process to another one or even send commands and requests, especially when this channel is faster then normal Unix sockets, like shared memory.

But how do you use this efficiently? I mean, a process doesn’t get an Event for a change in shared memory, he always has to poll for it, right? But isn’t that too resource intensive if all the processes are polling their shared memory all the time? What other alternatives are there?

Answer 1

To get notification of a change using IPCs on a Unix or Linux system, I could think of different technique without resorting to polling.

1st Blocking Read

One could use a file descriptor (a file, a Unix socket, a pipe or named pipe, an IPC queue, etc.). The consumer will read this file in a blocking way (a timeout is perhaps advised). The producer will write something to this file descriptor once it has updated the shared memory. Thus the consumer would get awaken from the read when this happen and go read the shared memory. The consumer will be in sleep state, so not consuming resources (like CPU) while waiting.

One could even use select for the consumer to wait for several file descriptor at the same time.

2nd Signals

The consumer would be awaken by a signal sent by the producer. The producer sends a signal (SIGUSR1 for instance) to the consumer once it has updated the shared memory. The consumer had subscribed previously to the signal and can handle the request. It is a bit more complex to handle because the even can be triggered at any time, so the design of the consumer is more difficult.