Please, direct messages to the list.
-------- Forwarded Message -------- Subject: Message privé sur le sujet suivant : [libuv] uv_timer_start() don't use timerfd_settime() on Linux. Date: Mon, 29 Sep 2014 02:21:48 -0700 (PDT) From: Jean-Christian de Rivaz <[email protected]> To: [email protected] Hi Saúl, thanks for your response. Le lundi 29 septembre 2014 08:28:31 UTC+2, Saúl Ibarra Corretgé a écrit : Hi Jean-Christian, On 09/29/2014 01:06 AM, Jean-Christian de Rivaz wrote: > Hello, [...] > The jitter of the sync() call time is smaller than 1ms, something that > the current libuv is unable to do. > 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. 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. 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. > 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. Best Regards, Jean-Christian
signature.asc
Description: OpenPGP digital signature
