I agree with the message below. UV has not periodic timers, or it has wrong/unexpectable periodic timers.
This should be taken into serious consideration. 2014-09-29 11:45 GMT+02:00 Saúl Ibarra Corretgé <[email protected]>: > 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 > > > -- Iñaki Baz Castillo <[email protected]> -- 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.
