Earlier in this chapter, we saw in Table 1 : A quick comparison of the simple alarm(2) API and interval timers, that, although the interval timer [get|set]itimer(2) APIs are superior to the simplistic alarm(2) API, they still lack important modern features. The modern POSIX (interval) timer mechanism addresses several shortcomings, some of which are as follows:

• The resolution is improved a thousand-fold with the addition of nanosecond granularity timers (with the addition of an arch-independent HRT mechanism, which is integrated into 2.6.16 Linux kernel onward).
• A generic sigevent(7) mechanism—which is a way to handle asynchronous events such as timer expiry (our use case), AIO request completion, delivery of a message, and so on—to handle timer expiry. We are now not forced to tie timer expiry to the signaling mechanism.
• Importantly, a process (or thread) can now set up and manage any number of timers.
• Well, ultimately, there's always an upper limit: in this case, it's the resource limit RLIMIT_SIGPENDING. (More technically, the fact is that the OS allocates a queued real-time signal for every timer created, which is thus the limit.)

These points are fleshed out as follows, so read on.