Re: Repeated timeouts period

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

(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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]