3 ms·

timerfd and it's counterparts in bsd/osx kqueue are absolutely essential to write fast I/O code. it's the stuff that powers node.js and such. the kernel has it

• tptacek 15y ago
  I don't buy it. I've scaled up code with tens of thousands of millisecond-granular demand-scheduled timers without a special kernel interface for them. Timers are a straightforward data structure problem. The only kernel hook you need to support them has been a part of select(2) and poll(2) for decades. I'm see the point of timerfd(2), don't get me wrong. I'm just saying: a performant timer implementation only needs to tell the kernel one thing: when the next timer fires. Unlike poll(2) and select(2), which have O(n) bottlenecks in the u/k interface, timers are performant in pure userland code. gettimeofday(2), on the other hand... there's a problem.
  • exDM69 15y ago
    I think I'm not on the same page with you. Are you suggesting that there is no need for timerfd and it's kqueue alternatives because you can have a priority queue that has the timer values and every time you call select/poll you look at the smallest value and wait until that? If so, that approach is very limited. It cannot be used in a multithreaded environment effectively, because if you want to cancel or change the time of the next timeout while select/poll is blocking, you will have to somehow wake the polling thread to inform it of the change, adding overhead and complexity. Imagine a select/poll call for every TCP socket you have and a timeout for each one of them. select/poll interface is also quite limited, you can't e.g. tell it which clock to use. I frequently work in a soft real time environment and I need to rely on high precision timing like CLOCK_MONOTONIC. Also, select and poll have other problems, which is why epoll and kqueue were created in the first place.
    • tptacek 15y ago
      I said "tens of thousands of millisecond granular timers", you can safely assume multiple timers on any given socket. You are describing something as complicated that has been a feature of every major event library since ACE_Wrappers. I'm at a disadvantage arguing about working with evented timers in multithreaded environments, because generally I event to avoid threads. In environments where I've done both (for instance, Cocoa), I dedicate a thread to the event loop and give it a message queue interface to the other threads. "Waking the polling thread" is pretty straightforward. Just set up a pipe and ping it when you have a message you need delivered immediately. That's no more expensive than "timerfd". I'm not arguing that select/poll are superior to epoll and kqueue (although select is just fine for many applications; why would I care, though; I don't write directly to select or kqueue). I'm saying that the Unix interface to timers isn't unscalable, and the scalability problems are in userland. Unlike select/poll, which did in fact have an O(n) problem in the u/k interface, the Unix interface to timers isn't a bottleneck.
      • jrockway 15y ago
        ev even has a watcher type, ev_async, specifically for waking up the event loop from another thread.