On Mon, Sep 29, 2014 at 2:11 PM, Saúl Ibarra Corretgé <[email protected]> wrote: > On 09/29/2014 01:28 PM, Ben Noordhuis wrote: >> On Mon, Sep 29, 2014 at 8:24 AM, Saúl Ibarra Corretgé <[email protected]> >> wrote: >>> timerfd would create a file descriptor per timer, that's one million fds >>> if we have one million timers, vs 0 fds which the current implementation >>> uses. >> >> That's not strictly necessary. Libuv could use a per-event loop >> timerfd and multiplex timers on top of that. >> >> There would be some system call overhead - an extra timerfd_settime() >> call before some/most calls to epoll_wait() - but it's probably not >> hugely expensive. >> > > I understand we could achieve sub-millisecond precision like that, > right? But it wouldn't "fix" the initial exposed problem here since we > still don't account for the duration of the callback... unless I missed > something :-)
I have no opinion on whether you should account for callback time, I just wanted to point out that it's possible to use timerfds without undue overhead. A clear reason for using a timerfd is that timerfds are usually more precise than epoll_wait() with its default 50 us timeout slack. (You can adjust the slack with the PR_SET_TIMERSLACK prctl() but you can never reset it to exactly zero because that resets it to the timer slack inherited from the parent process or thread.) Apart from slack, the timeout argument to epoll_wait() is a lower bound; the system call may sleep for longer than that. Timerfds give you better (albeit not perfect) control over the sleep period. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
