Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

[Martin Z. <co...@mz...>]

Hi Michael!

> A (double) linked list has several memory objects. As many timers are
> "one-shot timers" they may be created and destroyed very regularly. This
> would lead to lots of malloc()/free() calls.

I was not really thinking of a "real" linked list.  Memory allocation 
and re-usage wouldn't change at all, I just thought of adding one or two 
pointers so that the memory slots could be looped in a pre-defined order 
instead of in the order of the allocated memory.

> 2. Probably I have found the problem with "twice evaluation": there are
> some lines of code in timer.c (but probably not in timer_group.c):
>
> /* one-shot timers should NOT fire immediately, so delay them by a
> single timer interval */
> if (one_shot) {
> timer_inc(timer, &now);
> }
>
> so even if a new timer is added to the list after the currently being
> processed timer, it will not be triggered in the current loop.

(That's only true for one-shot timers.)  When I started changing the 
timer code, I didn't really get why one-shot timers needed to be 
delayed.  However, I fear that changing this behaviour might break a 
*LOT* of code.

> IIRC the timer-groups have been introduced to avoid "fading" of timers
> because of different execution time... is this correct? is there any
> other reason for having these groups?

I have originally added timer grouping because sometimes it is very 
useful to be sure that things belonging together actually happen 
together.  For example, I have implemented an interface for the MPD 
audio player using lcd4linux and python.  Polling MPD for its status 
takes quite a while (I think it was in the order of 300 ms).  Now image 
you've got a few text widgets and a timer for polling.  If you are 
unlucky, polling happens between updating text widgets that belong 
together.  This looks ugly in my case, but it may lead to other 
problems, depending on what the user tries to achieve.

With grouping, all a user has to do is to set timers for widgets 
belonging together to the same interval.  They are then updated one by 
one in an "internal" loop, and only then the main loop regains control.

I remember another problem: image a couple of text widgets set to an 
update interval of 1000 ms and a scroll interval of 250 ms (the times 
are arbitrary values here).  Without grouping, scrolling wasn't 
synchronous (at least when other things like polling were happening) -- 
with grouping, it is.

> I think there should be a better solution for this. probably some kind
> of "quantisation", which means that timers cannot have an arbitrary
> execution time, but must fit into defined values (eg every 10 msec). So
> if a 50 msec timer which is executed at 352 msec would get executed next
> time not at 402 msec, but rounded down to 350 msec

I don't think that this would really help with the above-mentioned 
problems. :)

> 3. I think having both timers and timer groups is a nuisance. Shall we try to "merge" them?

I tried to when I coded timer grouping, but my brain sort of freaked out 
when I tried to add delayed one-shot drivers... :)  But maybe a couple 
of brains can work it out.  I'd still rather like to keep the grouping, 
though...

(Sorry for this incoherent email, I'm quite tired.)

Best regards,

Martin
-- 
www.mzuther.de
www.radix-musik.de