Hi, > > Periodic timers are a bit hard. Some people expect that the timer > compensates for the time spent in the callback, some don't cause they > want the interval to be preserved across callbacks. It's also quite > messy to handle the case in which the callback takes longer than the > next interval. > > > A period is something very well defined from the mathematical point of > view. Engineer and scientist use that definition: the period is the > reciprocal of the frequency. Current libuv timer can't yield nothing > close to the definition of a frequency. Linux timerfd_* syscall can do > that. If anyone expect to wait a fixed delay after the end of the > callback, it must use a single shot timer (not a periodic one) and > restart it and the end of the callback. >
TBH I plan to propose the removal of repeating timers for libuv 2.0.0. There is nothing special about them in libuv, we just rearm them with the 'repeat' value. The user may as well do that himself. > > Having that said, timers on libuv don't compensate for the amount of > time spent in the callback. > > > So libuv lack a periodic timer feature. > > > > I have two questions: > > 1) is there anything that would prevent libuv from > > using timerfd_settime() on Linux ? > > There are a couple I can think of: timerfd was added in Linux 2.6.22, > and I believe we still support older kernels > > > It's difficult to understand this argument as almost half of the Linux > syscall already used today by libuv are only available in kernel newer > than the kernel that introduce the timerfd_* syscalls. I have merged the > informations from the > https://github.com/joyent/libuv/blob/master/src/unix/linux-syscalls.h > and the http://man7.org/linux/man-pages/man2/syscalls.2.html then sorted > the result by kernel release: > > | > pipe2 1.0 > epoll_create2.6 > epoll_ctl2.6 > epoll_wait2.6 > inotify_init2.6.13 > inotify_add_watch2.6.13 > inotify_rm_watch2.6.13 > epoll_pwait2.6.19 > eventfd2.6.22 > utimensat2.6.22 > --------------------------------- > timerfd_create2.6.25 > timerfd_gettime2.6.25 > timerfd_settime2.6.25 > --------------------------------- > epoll_create12.6.27 > eventfd22.6.27 > inotify_init12.6.27 > dup32.6.27 > accept42.6.28 > recvmmsg2.6.33 > preadv2.6.30 > pwritev2.6.30 > sendmmsg3.0 > | > > It seem clear from this observation that addin timerfd_* syscalls into > libuv don't break the usual way libuv handle if a Linux syscall is > available or not. > Note that we fallback in case those are not available. For example: libuv will use accept4 if possible, but fallback to accept otherwise. I believe there are still a ton of 2.6.18 kernels around. Not to mention, timerfd changed between 2.6.22 and 2.6.23, so we'd have to deal with that perhaps. > but more importantly, > 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. > > > I don't understand this argument either as the same limitation apply to > others very importants syscalls like accept* for example and yet don't > hurt anyone. Did really anyone tested the libuv scale up to one million > timers ? A this scale I suspect that it will be better to sort the > timers to only expose the shorter up to the thread number witch is > anyway limited by the kernel. > Sure, if you have one million connections you'll need one million fds, but you might have far more timers than connections. Checkout our million timers benchmark, it creates 10 million timers without breaking a sweat. > > 2) Is there any motivation to do that ? > > > > Hopefully others chime in as well, but I'm not really inclined to go > this route, for the aforementioned reasons. I'm open to be proven > otherwise though :-) > > > I sincerely hope my response might change your mind. I don't understand > why a modern project like libuv that advertise "High resolution clock" > in his feature highlights would stay a second citizen in that subject. > You are free to submit a patch and prove me wrong, my opinion is irrelevant if code can prove it otherwise :-) Though, before you jump into writing any code I'd wait until other core devs have expressed their thoughts. Regards, -- Saúl Ibarra Corretgé bettercallsaghul.com
signature.asc
Description: OpenPGP digital signature
