I meant to say of only a milli second.
On Monday, April 20, 2015 at 4:01:09 PM UTC+2, Andrius Bentkus wrote:
>
> While toying around with libuv I have found out that the epoll timer has a
> resolution of only a second which creates a drift.
>
> If we do something like
>
> ```js
> var count = 0;
> var last = count;
>
> setInterval(function () {
> count++;
> }, 1); // every millisecond
>
> setInterval(function () {
> console.log(count - last);
> last = count;
> }, 1000); // after a second
> ```
>
> With libuv (this is nodejs code, but the same would hold true for C/libuv
> code) we get < 1000 events per second. On my machine its around ~923 events.
>
> Now this is impossible to solve with epoll having a timeout based on
> milliseconds and not nanoseconds, but I just wanted to post this:
> https://github.com/famz/linux/tree/epoll_pwait1
>
> This patch introduces an epoll api which works on nano second resolution
> and would allow us to get the thing running sufficiently fine graind. The
> author wants that feature to get into the kernel for qemu.
>
> Here is the entire discussion on the linux kernel mailing list
> http://thread.gmane.org/gmane.linux.kernel.api/8250
>
> I just wanted to post this so we would keep a look out for when the
> feature hits the kernel
>
--
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.
