3 ms·
The article's conclusion is completely wrong because it misses two crucial points: 1. On multicore machines you want to process timers in parallel on multiple
by devit 2y ago
The article's conclusion is completely wrong because it misses two crucial points:
1. On multicore machines you want to process timers in parallel on multiple cores. With userspace timers you either set the same timeouts on all threads and have unnecessary wakeups or distribute timers to cores ahead of time which leads to increased latency if a thread is stalled for any reason. I think this is unfixable without a dedicated timer API.
2. Good timer APIs let you set a time _interval_ for when the timer expires, which is essential so that the system can group timers and reduce wakeups (i.e. you process all timers where the lower bound has been reached before going to sleep, but don't wake up until the upper bound arrives). Most or all "wait with timeout" APIs only have a single timeout, although this could be fixed.
- gpderetta 2y ago> On multicore machines you want to process timers in parallel on multiple cores. By experience I almost never want to run my timer callbacks on a random core and always want it on a specific core. With the typical one event loop per thread, you would register the timer with the thread you care about. This is going to be very application specific.