Specify absolute deadlines, not relative timeouts
I don’t remember where I recently read this, but it was probably related to POSIX (real-time) semaphores.
It’s common for blocking operations (reading from a file or socket, acquiring a mutex, etc.) to offer variants with a timeout argument: when the operation blocks for longer than the timeout, it returns with an error value.
Exposing a deadline instead (with respect to an absolute time value like the system clock) leads to much more robust programs. Rather than specifying the amount of time for which an operation may block, the operation should return with an error value once the time is later than the deadline.
A timeout argument is preferable only when we don’t really care how long our program blocks, but don’t want it to block too long. However, whenever we perform some work alongside the blocking operation, or want to make sure not to hammer on a resource (but still want to use it as much as possible), a deadline is better. Instead of counting time from the beginning of the blocking operation, it lets us count from whichever program point at which we query the system clock. All intervening operations, interrupts, context switches, etc. are then considered in the deadline.
If you want to expose a timed variant of a blocking operation, offer a deadline argument. They make correct programs easier to express at the expense of quick hacks that only want to “block, but not too much”. Timeouts are the other way. Even better: timeouts are readily be expressed in terms of deadlines, while the reverse transformation is much more convoluted.
