from #7816 (comment)

This topic comes up in frequently enough that I usually forget the answer .... "why do we need to have a max wakeup time of 1 second instead of unbounded" for the EventLoop implementations. IIRC the answer is when we schedule tasks we don't check if the new time results in a sooner deadline than the previous wakeup on the EventLoop. I think I investigated other events from outside the EventLoop and they should be invoking wakeup (and we have an atomic boolean protecting wakeup to avoid too many system calls). I wonder if now that we are saving the prevDeadlineNanos, and we have a timer mechanism independent of epoll_wait, if we can avoid waking up every second (and additional timerfd_settime system calls), and instead only wakeup when necessary.

Potential benefits:

• if there are no scheduled task, we only wakeup when I/O occurs
• we will be more responsive to schedule tasks (because we can adjust the wakeup to the minimum delay as new tasks are scheduled)

Potential negatives:

• in the degenerate case if someone schedules tasks in decreasing order of expiration (10 seconds from now, 9 seconds, 8 seconds, etc...) we will have to touch the the timerfd_settime on each schedule. For outside the EventLoop we wouldn't have to wakeup the epoll_wait call (assuming timerfd_settime is thread safe).

@normanmaurer @carl-mastrangelo - wdyt? We could do the same thing for kqueue too (we would need to use a timerfd equivalent there too though).