Le mardi 30 septembre 2014 13:52:29 UTC+2, Bert Belder a écrit : > > > Your idea is interesting. After reading the reactions on my initial post, >> I wonder if it's a constructive proposal to split the question into >> multiples aspects: >> >> 1) Should libuv offer API for periodic timer ? The actual implementation >> do not and in fact correspond to a one shot timer restarted at the end of >> the callback. If the response is no, then actual API and documentation >> should be changed. If the response is yes, the implementation should be >> changed. I hope that the libuv community found an advantage to respond yes >> to this question, as periodic timers is certainly a common feature request >> and libuv is in best place to implement it. >> > > I don't think so. The current model was inherited from libev, which had no > concept of "requests" like libuv does, instead it had only "handles". > Also the earlier versions of libuv didn't support `uv_cancel(uv_req_t*)` > so at the time we had to make a timer a handle to support stopping the > timer. > > Saùl, Ben and myself already had some sort of informal agreement that a > 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); >
Ok, this has a least the advantage to make the situation more clear and don't prevent the potential addition of periodic timers in the future. > 2) Should libuv use timerfd to implement the aspect 1 in case the response >> is yes ? Certainly no in general as timerfd is usable only on Linux >> starting from kernel 2.6.23 or so. Depending on the performances of the >> general code for periodic timer (if there is any) timerfd might allow an >> improvement, but this is too early to be certain about that at this stage. >> > > I don't think we should use timerfd for uv_timer / uv_timeout timers. > These timers are guaranteed to be fast and highly scalable, not precise. If > we use timerfd on some linux flavors, they will be slow-and-precise on some > operating systems, and fast-and-coarse on others. It makes libuv as a whole > less useful. > Agree. > 3) Should libuv offer a high precision timer API ? From a API point of >> view, it would be better to have a single API that scale and stay precise. >> An example on how to use timerfd watcher will be an immediate advantage for >> not too old Linux kernel users. >> > > Maybe - I like to think use cases; what are you trying to do? Writing a > game loop, rendering video, synchonizing clocks? > My actual application need to extract data from a hardware at a maximum interval of less than 100ms, but ideally about 50ms. The hardware already no a nice work in buffering the data in a large DMA but the tricky part is that it need a precise synchronization with the TAI maintained by the Linux kernel using a GPS. For this I need the low jitter and correct phase provided by timerfd. I don't strictly need libuv for this application, but this would help as on the other end there will be file and TCP streams feed by the data. Node.je is also running on the system for the configuration, making libuv a common library. - 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.
