Le lundi 29 septembre 2014 12:03:39 UTC+2, Saúl Ibarra Corretgé a écrit : > > > > 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. >
Yes, fallback is the way to go. Don't try to use eventfd in kernel 2.6.22: see only it as an early experiment. > > 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. > Note that the 10 million timer benchmark will not be affected if you expect a non periodic result. There is actually no possible libuv benchmark for periodic timers as libuv is currently unable to implement a periodic timer. It only implement a repetitive delay that is nothing periodic. > > > 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. > Ok. Best Regards, Jean-Christian -- 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.
