On Tuesday, September 30, 2014 2:25:37 PM UTC+2, Iñaki Baz Castillo wrote: > > 2014-09-30 13:52 GMT+02:00 Bert Belder: > > next iteration of libuv would only support one-shot timers with an API > > similar to this: > > `uv_timeout(uv_timeout_req_t* timeout, int64_t timeout, uv_timeout_cb > > callback); > > While that is great it also completely drops the "periodic timer" > feature from libuv. Ok, current periodic timers are wrong but, should > libuv provide correct periodic timers (those in which the callback > execution time does not affect the next execution)? > > By just providing the uv_timeout() request, users cannot implement > real periodic timers. >
Building real periodic timers isn't that hard, the user can look at uv_now() or uv_hrtime() and compute the difference between the actual time and the scheduled time for the callback. With that information one can compensate for being late, and schedule the next callback a bit earlier. We could make it a little bit more convenient by having an API that schedules a callback on for an absolute loop time (instead of a relative one). Note that you can already *get* the time very accurately with uv_hrtime(). The missing piece (?) is scheduling a timer with high precision. But I can't really think of any valid use case for this, which makes it hard to tell whether any api is actually useful. I am not so much in favor of adding features that nobody really needs (yet), which is why I'm asking for the use case the TS needs it for or has in mind. - Bert -- 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.
