As a very interesting aside, wouldn't it be wonderful if one could actually trace the flow of the sender and receiver processes as they execute? Well, Linux provides several tools to do precisely this. Among the more sophisticated ones is a software called Linux Tracing Toolkit next generation (LTTng).
LTTng is really powerful; once set up, it has the ability to trace both kernel and user space (although tracing user space involves the application developers explicitly instrumenting their code). Well, your author used LTTng to perform a trace of the system (kernel-space) while the previous processes ran; LTTng did its job, capturing trace data (in a format called CTF).
Then, the superb Trace Compass GUI application was used to display and interpret the trace session in a meaningful manner; the following screenshot shows an example; you can see the point at which the sender sent the signal to the receiver process via the sigqueue(3) library API, which, as you can see, translated to the rt_sigqueueinfo(2) system call (its entry point inside the kernel shows up as the syscall_entry_rt_sigqueueinfo event as follows).
Next, the receiver process (sigq_trc_recv here) received (and then processed) the signal:
(As a fun thing to do: calculate the time delta between the real time signal being sent and the signal being received, bookmarked in purple and red color, respectively. It's approximately 300 ms (microseconds).)
The details of LTTng is not within the scope of this book's coverage; please see the Further reading section on the GitHub repository.
For completeness, we note the following APIs to send signals as well:
- pthread_kill(3) : an API to send a signal to a particular thread within the same process
- tgkill(2) : an API to send a signal to a particular thread within a given thread group
- tkill(2) : a deprecated predecessor to tgkill
Let's ignore these for now; these APIs become more relevant in the context of multithreading in later Chapter 14, Multithreading with Pthreads Part I - Essentials, in the book.