3 ms·

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 que

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

by exDM69 15y ago

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.