Re: [AD] minor fix

[ 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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/