Let's say we use signaling as the event-notification mechanism to tell us that a POSIX timer has expired, and let's say that the timer-expiry period is a very small amount of time (say, a few tens of microseconds); for example, 100 microseconds. This implies that every 100 microseconds the signal will be delivered to the target process!

In these circumstances, it's quite reasonable to expect that the process, being delivered the same ever-repeating signal at such a high rate, cannot possibly handle it. We also know from our knowledge on signaling that, in cases precisely like this, using a real-time signal would be far superior to using a regular Unix signal, as the OS has the ability to queue real-time signals but not regular signals—they (regular signals) will be dropped and only a single instance preserved.

So, we shall use a real-time signal (say, SIGRTMIN) to denote timer expiry; however, with a really tiny timer expiry (for example, as we said, 100 microseconds), even this technique will not suffice! The process will certainly be overrun by the rapid delivery of the same signal. For precisely these situations, one can retrieve the actual number of overruns that occurred between the timer expiry and the actual signal processing. How do we do this? There are two ways:

• One is via the signal handler's siginfo_t->_timer->si_overrun  member (implying we specified the SA_SIGINFO flag when trapping the signal with sigaction)—this is the overrun count.
• However, this method is Linux-specific (and non-portable). A simpler, portable method of obtaining the overrun count is by using the timer_getoverrun(2) system call. The downside here being that system calls have far more overhead than a memory lookup; as in life, when there's an upside, there's also a downside.