Le mardi 30 septembre 2014 18:25:43 UTC+2, Bert Belder a écrit : > > On Tuesday, September 30, 2014 6:10:23 PM UTC+2, Jean-Christian de Rivaz > wrote: >> >> Le mardi 30 septembre 2014 17:26:10 UTC+2, Bert Belder a écrit : >>> >>> >>> 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. >>> >> >> Sorry, I have a radical different view. I build Linux embedded system >> since more than 15 years and I can't remember a single one that don't use >> periodic timer. >> > > Note that I was speaking of a high-precision periodic timer. > I'm saying that a sloppy one (as sloppy as we have today or slighly > better) can easily be built on top of a one-shot timer. >
Ok. The question is still there about an API for a good (not high precision) periodic timer. > I am curious for one these embedded systems used high-precision (periodic > or not) timers. > > >> Most of the times this is related to the hardware >> > > Maybe on embedded systems, I don't know. Can you give me examples of > hardware other than the display (see below for that)? > Are you trying to do something very realtime like controlling a robot? > I have described my application a few post before. This one specifically require low jitter and correct phase. Most others applications I have see are not so specific, but still require relatively good periodic timer. A simple example is a cursor that can be pressed to repeat the direction of a selection but the processing to display each selection vary widely. An other simple example is a collection of devices that sample values once per second, regardless of the work need to do the sampling that could change depending of the configuration. Processing of regulation or filtering can be simpler if the input data are sampled with a good periodicity.If you think about it, you rarely expect that a regular physical action depend on a unknown delay deeply into the code execution. > or user interface where it is expected to not have delay that depend of a >> callback execution time to get a smooth operation. >> > > I think for user interfaces 60fps is generally considered good enough. > This requires a timer with at most a (1000 / 60) ≈ 16ms interval, which is > well within the range of what the current timer implementation can do. > No. The current implementation have no way to grant any periodicity as it is completely dependent of the callback time execution. See my initial post or try it. - 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.
