Now that we have looked at using the (simplistic) alarm(2) API, it's important to realize that it has several downsides:

• A very coarse granularity timeout (a minimum of one second, which is a very long time on a modern processor!)
• Running more than a single timeout in parallel is not possible
• It's not possible to query or modify the timeout value at a later point—attempting to do so will cancel it
• Mixing the following APIs can result in problems/conflicts (in the following, the latter API may be internally implemented using the former)
  • alarm(2) and setitimer(2)
  • alarm(2) and sleep(3)
• It's always possible that the timeout occurs later than expected (overrun)

As we progress through this chapter, we will find more powerful functions that can overcome most of these issues. (Well, to be fair, the poor alarm(2) does have an upside: for simplistic purposes, it's really quick and easy to use!)