On 18.09.2013 10:00, Michael Schnell wrote:
On 09/18/2013 09:53 AM, Sven Barth wrote:
I wouldn't use the timeout constant for this. If you have two timers
of which the greatest common denominator is 1, but nevertheless rather
large (e.g. two primes) then you'd loop unnecessarily (I know this is
a constructed example, but nevertheless one should care for this!).
I'd instead suggest to implement the timerloop of each timer as a
thread that waits its timeout time on a event (so that it can also be
stopped) and then notifies the mainthread using Queue().
Right you are. (I just wanted to keep this as simple as possible for a
starter.)
You simply could use a sleep in the timer loop,. This would be arch
independent out of the box. But it would impose accumulative delays
depending on the CPU performance.
I would not use Sleep as you need to be able to cancel the timer (e.g.
Timer.Enabled := False or the application terminating). At least on *nix
based systems you'd need to artificially send a signal which is why I'd
prefer the event way which you can simply set in SetEnabled and Free.
An more advanced timer implementation would use arch depending OS-based
timers. This would allow for a much more exact timing.
Of course. The timer component should be written in a way that it can be
implemented in a platform specific way as well.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
