[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Chris wrote:
Peter Wang wrote:
I'm not entirely sure what you mean. The code in question is not so
much to slow down the rate at which the callbacks are called, but to
_catch up_ when necessary.
Right, but when you aim for the timer thread to loop ~100 times per
second, it will stunt performance if it can be set to loop faster, if
not cause for problems. I'm just saying I don't think it's a good idea
to aim for any particular rate to call the timer callbacks, other than
as fast as possible.
[again, we're talking about the background thread here, not the timer
thread: the background thread handles input devices, pushing data to the
sound card, etc.]
"As fast as possible" doesn't work for a background thread. It
necessarily has to put itself to sleep at every iteration, otherwise it
will be competing with the primary thread for the CPU, leading to bad
performance for user code.
The question is how long to sleep for. The ~100 times per second not
completely arbitrary. You pretty much cannot make a thread sleep for
less than 10 ms on Linux (and others). Maybe if you tweak some kernel
options...?
I'm planning on looking through the threading code myself to see
exactly what it's doing and how, but I'd imagine you just take the
elapsed time since the last iteration, determine how many times the
timer should of been called, and call it that many number of times,
while saving any sub-whole number remainder to add to the next
iteration counter.
I don't know if it's necessary, but I encourage you to try. It's done
for the timer thread though (see uptimer.c and timer.c).
Meh. I suck at explaining what I mean. I'll just look through the
thread timer handler code and see what's going on.
Great! The more eyes on it the better.
Peter