Re: weird gtk_timeout_add ...

[Peter Rottengatter <peter rottengatter de>]

Eric M. Monsler wrote about "weird gtk_timeout_add ..." :

> Peter Rottengatter wrote:

> > 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.

You haven't read what I wrote: The handler can keep up very well, as there
is no influence at all if I do a lot of stuff in the handler, or not. Then
again the same thing happens with pretty much the same numbers with a
machine that is a fair bit faster.

Also, there is very little CPU load during execution of that program part.


> 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.

This is obvious. However it does not apply. Note: it does not spiral to 
death even though what is done in the handler is always the same.

Note also: Blocking is not required for it to become a problem.


> 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.

No need to tell me ;-) I have written some kind of real-time kernel a
couple of years ago, and it has been used by several hundreds of people
throughout the world.


> 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.

I can do without here, even though this part of the code indeed accesses 
a device driver written by me (CAN bus).


Cheers  Peter
-- 
---------------------------------------------------------------------
      Dr. Peter Rottengatter       peter rottengatter de
                                   http://www.rottengatter.de
---------------------------------------------------------------------