Now look at this, the postbox is already half finished. We only have to extend it with a few more exotic options for those children with very special ways to express their wishes in rather unusual ways. With these extensions, Santa's postbox will be truly versatile and future proof for the coming years of digitalization.
Usually, signal(7)s in a Linux program are similar to interrupts on the bare machine: At any point in time, the underlying execution engine (OS or CPU respectively) invokes the (signal/interrupt) handler function asynchronously. The handler interrupts the thread's control flow and resumes it on return in such a way that it's transparent for the executing control flow. This "everywhere and every time" comes at the cost that we have to think about signal-safety(7).
When you think of Unix signals, you usually only think about the signal numbers that are invoked without any kind of payload. However, with rt_sigqueueinfo(2), the signal sender can attach one 32-bit word of information to the target process, whereby we can use it as an incoming port of our postbox! What a happy day! We only want to look at the receiving side; you can send signals with a payload with the shell command kill(1):
/bin/kill -USR1 --queue 3 PID
On the receiving side, the queue payload can be extracted from the siginfo_t when using a normal signal handler that was installed with sigaction(2). However, for our postbox, we want to integrate the signal handling with our epoll-based framework, whereby we also avoid all problems regarding signal safety. For this we will use a signalfd(2):
int signalfd(int fd, const sigset_t *mask, int flags);
A signal file descriptor is a special kind of descriptor that will produce struct signalfd_siginfo objects when we read() from it, if our thread received a signal. The signalfd will listen only for those signals that are indicated by the given signal set mask.
Once you have properly integrated a singalfd for SIGUSR1 and for SIGUSR2, the postbox can now also output received signals with payload:
signalfd[uid=1419804,pid=10104] signal=10, data=3
While children that use sigqueue() have to have short, very short, indeed only 32-bit long wishes, POSIX message queues (mq_overview(7)) allow for much longer wish lists. This IPC mechanism is less known but has the unique properties that the message queue is independent from the existence of a process and it can outlive the creating process. Thereby, a sender can send a message to a message queue, even if the receiving process has not been started yet or is currently restarting. If the send operation succeeds, the sender knows that his message can be read by the receiver at some point in time. Perfect for Santa's postbox, that in its current work-in-progress state, is more often in the workshop than outside.
In essence, message queues are special files that we create with mq_open(2) and that become visible under /dev/mqueue unless we explicitly delete the message again with mq_unlink(3). For the rendezvous message queues use symbolic names, like FIFOs and domain sockets. With a look at /dev/mqueue/NAME, we can see the state of a message queue (postbox being the symbol NAME):
$ ./mq_send XYZ
$ cat /dev/mqueue/postbox
QSIZE:3 NOTIFY:0 SIGNO:0 NOTIFY_PID:0 box
Here we see that the queue has three bytes (XYZ) pending queue. That our postbox process can receive with mq_timedreceive(2) on start:
$ ./postbox
...
mqueue[prio=0]: XYZ
Today's task is to integrate both the signalfd and the mqueue mechanism in our postbox from yesterday.
epoll and therefore be integrated in our postbox.O_RDONLY | O_CREAT as flags for the mq_open as you not know if you are the first postbox process after the system boot.signalfd.Last modified: 2023-12-01 15:52:27.972084, Last author: , Permalink: /p/advent-13-postbox