Re: [Lcd4linux-devel] Twice eval. patch

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

Hi Marcus,

thanks for your bug report and two patches!  I am the one who is 
responsible for rewriting the whole timer code about two years ago, and 
I have also added the timer group code.  However, I think that the 
problem lies in the general way that timers are handled in "lcd4linux" 
and that it's current manifestation in my timer group code is just one 
of the possible problems.  I do not want to defend my code, it's just 
that I've always had a bad feeling about the way that the timers are 
processed in "lcd4linux".

See, timers are (in)activated by a setting a variable to a defined state 
(I have actually *named* these states for easier reading in revision 
1182).  Inactive timers are reused by simply looping through all timers 
and looking for the state "inactive".  And this is where the problem 
lies -- while lcd4linux gets a lot faster by not allocating and freeing 
memory for each and every timer, new timers may end up in any slot.  As 
timers are processed by simply looping through all available timer 
slots, this may lead to some timers being processed more than they 
should (if during looping, a new active timer is placed in a slot with a 
higher number than the loop counter).

So while your patch may work fine (I haven't looked at it yet, as I have 
tried to concentrate on the problem itself), it might be time to fix 
timer processing instead.  We all of a sudden have a problem that we can 
understand.  Just imagine that a similar but much more complex problem 
creeps up again in a couple of months... :(

Here is my solution to the problem (feel free to post your own 
solutions!): right now timers can have two states, either active or 
inactive.  New timers are set to "active" and this is where the problem 
lies.  I have thought of adding a third state "on hold".  New timers 
should be set to "on hold" to make sure they are not processed in the 
current loop.  Now, each time "widget_timer_update()" is called, it 
should change all timers from "on hold" to "active" so will get 
processed from then on.

Any thoughts on this from you or anyone (Michael)?

Best regards,

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