Le duodi 22 vendémiaire, an CCXIV, Valdis Kletnieks vt edu a écrit : > Something to keep in mind - the system's *internal* clock is usually going > tick-tick-tick at some high speed (100HZ to 1000HZ for recent Linux > kernels, for example). In fact, it is much more accurate. For example, on a moderately recent PC, Linux claims microsecond accuracy, that is: the value returned by gettimeofday has non-zero less-significant digits in the microsecond field. That is possible because the hardware has a variety of counters updated at a constant rate, from the 1193182 Hz historic PIC to the Time Stamp Counter of recent CPUs -- and I expect architectures others than PCs have similar features. (I wrote "claims" and not "has microsecond accuracy" because I do not know how NTP correction is applied to the hi-resolution time sources.) Anyway, that is not the point. > Given that you already *know* there's up to 0.5 seconds of difference, it > seems that what you want *isn't* "precisely the same time the internal > clock value changes". There is some misunderstanding here. When I wrote "internal clock", I was not refering to the operating system internal clock. I was refering to some abstract value relevant to my program. An "internal clock" is typically a variable of type "struct tv" or similar that holds the origin of the time. > What you want is a guarantee that *this* change > will be almost exactly 1 second since the last change - in other words, if > the last time it changed was actually at :45.34, you want the next one to > be between :46.32 and :46.36 or so... No, that is precisely what I do _not_ want. What I want, is that the n-th change will be almost exactly n seconds avter the time origin. Let me underline the difference: assume that the origin is 42.33. The first change will maybe occur at 43.34, to display "1"; 0.01 late, incompressible system latency, so long so good. The second change will occur at 44.34, the third at 45.35, then 46.34, 47.34, 48.34. But at that time, maybe some crontab will wake up and take some time, so that the update of the clock to "7" will only occur at 49.82, half a second late; well, if I do not want that, I need a real-time operating system, that is not a problem. The problem is the next update: if I use plain g_timeout_* functions, the next update will be scheduled for 50.82, again half a second late. The temporary slowness has cost me half a second, and that half a second will stay. What I want is that the timeout scheduling try to catch up the time. The last update was half a second late: the next update will be scheduled in 500ms and not 1000, and that is all. I will try and make a analogy. Every week, my boss pays me on Tuesdays (why Tuesdays? why not?). One week, he has been really busy, or he has had payment problems, he only pays me on Wednesday. The next week, I expect him to pay me on Tuesday as usual, not on Wednesday. (There is a small imperfection in this analogy: if one week my boss has really big troubles, and can not pay me until the next week, I expect to get twice the money, for both weeks. Whereas I do not care to update the clock twice in the same second.) One last point: I know exactly what I want to do with that timeout/clock business (but maybe I explain it badly), and I know exactly _how_ to do it too -- in fact, it is really easy, and just quite tiresome. The only reason I started this thread here was to know whether it was worth to take the time to have a clean reusable API and release it to the community. Obviously, the community do not need it.
Attachment:
signature.asc
Description: Digital signature