timers.h

[avvdr]

Hi Chris,
when I was playing with timers newly I saw your comments in the timers.h.
I have the following proposal:
1. Leave the existing timer handling available
advantage: no need to change a lot of code
2. add new functions like follows:
setMessageTimerX(Boxx *listener, int id,....)
So this can only be called by Boxxes (at the end it should be restricted to views - but now there is no separate class any more...).
If a timer registered this way fires, a message will be send to the particular view.
So we can easily define a TIMER_EVENT message, having the client ref as parameter.
New code can easily use this extended interface, have the timer handling in processMessage and can avoid the postMessage calls.
Even porting of current code would be easy at many places because the real handling is most probably in processMessage anyway.

This approach would combine the advantages of the current solution (precise timers, also for non view elements) with the ease of your new proposal.

Regards
Andreas

[Chris]

Firstly let me say I am a bit rusty on the code at the moment so if some of the following doesn't make sense than that will be why 

I seem to remember that soon after I wrote that information in timers.h I investigated why all the timercall functions just made messages and posted them to Command. I think actually that the current system isn't as bad as I thought, there just needs to be some changes.

My thinking when I am coding in this area is that threads made by Timers that enter client timercall functions are not within the main Command thread, and therefore cannot do certain things that should only be done by the Command thread. My little investigation turned up the fact that the only thing this applies to is operations within Boxstack. I think that if Boxstack were made thread safe internally - i.e. its main functions were mutually exclusive (to steal some Java words) then I think Timers could stay as they are, timercall functions would be able to update the GUI directly instead of making messages, and a whole lot of postMessage calls would be deleted. I believe this would make for simple and neat code that makes a whole lot more sense that the current stuff.

What do you think?

I am going to have an experimental go at this idea when I have finished the new live TV code - I'll get more of an idea if this is all correct then.

[avvdr]

Hi Chris,
my feeling is that it would lead to a lot of serious problems in a couple of view (boxx-) implementation if the code dealing with display functions could be called from within multiple threads (i.e. a key press and a timer firing at the same time). This would require all this code to become thread safe.
Currently the pattern is quite simple:
everything that is triggered by handleCommand or processMessage is promised to be called only from one thread at the same time

The question is:
What are typical actions to be done within a timer call?
I guess very often it is e.g. updating a (child) view or myself with creating new strings, GUI objects (or even views).
This would have to be thread safe...

I personally would stick at the current pattern to just send a message to myself when a timer fires in boxxes.
For other objects (e.g. players) things are different - they have threads anyway and thread safety has been an issue just from the beginning - so it's typically not a real problem to have timer calls from within different threads.

So at least I would prefer a timercall (message or callback - no big diff from my pov) for boxxes synchronized with the global mutex - this would free me from dealing with thread safety in the rest of the boxxes code.

At the end introducing additional syncing in the boxstack would make operations a bit slower - but I don't think that this is really an issue.

Regards
Andreas