Re: weird gtk_timeout_add ...

["Eric M. Monsler" <emonsler beamreachnetworks com>]

Peter Rottengatter wrote:
> Hmmm, the docs say the first parameter of gtk_timeout_add is the number
> of milliseconds between successive events triggering the timeout handler.
> So "gtk_timeout_add (10, check_progress, widget);" means call the handler
> check_progress every 10ms. Now the handler has as the first lines
> |  static int cnt=0;
> |  printf("%d\n",cnt++);
> So I'd expect counting to 1600 would take 1600 x 10ms = 16s. It doesn't.
> It does take twice as long: 32s. Using a 20ms timeout, the total time is
> still 50% longer than expected. The machine is not a particularly slow one,
> and the result is independent of what else is done in the timeout handler.
> This is GTK 1.2.5. Any explanations ?

Your program cannot keep up when the period is 10 ms.  Hence, the
handler is not called every 10 ms, but every 20 ms on average.

Your program cannot keep up when the period is 20 ms.  Hence, the
handler is not called every 20 ms, but every 30 ms on average.

Try every 40 ms.  Then 50 ms.

Fundamentally, an application framework handling periodic events and
blocking has a problem: if pending periodic events are queued, a death
spiral will result from any systematic falling behind.

Hence, the typical solution is to simply discard such events, calling
the handler as often as possible, up to the requested period.  

In some applications, such as 'soft realtime' kernels, etc. the same
problem is dealt with by telling the handler how many periods have
elapsed.  In hard realtime systems, events are typically queued, because
if we fall behind and crash, that is no worse than missing events.

This is a general answer to a GTK-specific question, but is an important
concept if you're really writing code that is trying to handle anything
that vaguely requires 10ms resolution.

Unless you're accessing some hardware FIFO that overflows in 10 ms, have
your handler called every 200 ms, and then figure out how long has
elased since you last were called (might be 200, might be 210, might be
220 ms) to determine how many 10 ms updates to perform.

If you are accessing something that overflows in 10 ms., rethink your
design and have a 'device driver' portion that buffers data into larger
chunks.


Eric M. Monsler
Overtired embedded SW guy.