Hi Iñaki, Le lundi 29 septembre 2014 14:21:42 UTC+2, Iñaki Baz Castillo a écrit : > > 2014-09-29 14:11 GMT+02:00 Saúl Ibarra Corretgé <sag...@gmail.com > <javascript:>>: > > I understand we could achieve sub-millisecond precision like that, > > right? But it wouldn't "fix" the initial exposed problem here since we > > still don't account for the duration of the callback... unless I missed > > something :-) > > > AFAIK epoll/kqueue/etc is needed to be notified about timerfd events, > right? If so we have the same issue since it may take some time since > timerfd fires until libuv checks it (exactly the current callback(s) > execution time). How to deal with it? >
If the application is quick enough to call epoll before a timerfd fire, the timerfd grant a high precision and phase for periodic fire. If the application is slow timerfd grand that futures periods are still in phase with the initial call. If the application is so slow that it completely miss a period, the number of expirations are in the uint64_t returned by the read() on the timerfd file. -- 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 libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
