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 ...
