Re: [AD] SetTimer for the timer

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-01-09, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Mon, 2006-01-09 at 02:15 -0800, Chris wrote:
> > > > It seems these would fit better than the current hackish way
> > > > of running a timed thread.
> > >
> > > Why is it hackish?  It's pretty straight forward.
> > 
> > Because they were originally designed to run in an interupt context, not 
> > concurrently with the main program (which has led to sloppiness and the 
> > mistaken belief that you can wait in a timer for something to occur in the 
> > main thread; eg. a mutex).

I agree that the whole area of timer callbacks is sloppy but I don't see
how the second part follows.  Anyway, not important.

> > To put it into perspective, if the timer was 
> > accurate and better prioritized so it would be used, anything that uses the 
> > software mouse or calls a sound/graphic function would randomly freeze solid. 
> > Granted the latter shouldn't be done anyway, and the former would hopefully 
> > be fixed in some way, but the current implementation clearly allows it.
> 
> The documentation always said that you should only use timers to set
> variables. I think, the best way around this would be a simple threads
> layer. And I mean very simple, basically allow to run a function in an
> alternate thread, maybe provide a simple mutex. That should allow to do
> anything you would want to abuse timers for (e.g. streaming music from
> the background). For more advanced threading needs, you still should use
> pthreads or something else.

*sigh*  Ok, I think I am just about ready to concede on this.  It's too
bad the pthreads-win32 is a bit heavyweight, otherwise we wouldn't be
having this discussion.

> And timers would stay what they are,
> callbacks which may get called at any time, and where you can only
> change a variable.

No.  Let's just remove the callbacks from the API, finally.

> Actually, you could easily simulate the current
> timers with such a threads API, al_current_time, and rest - so maybe we
> wouldn't need it anymore at all except in the compatibility layer.

The best way would probably be to combine threads with the events
system, once it is thread-safe and assuming the event and timer
subsystems are implemented efficiently.  Otherwise you have nothing more
than the 4.2 timer implementation (actually worse, since
al_current_time() and al_rest() only have millisecond granularity).

> > As well, there's problems making a single thread having to keep track of all 
> > the timers which can have different speeds. This is either handled by 
> > sleeping at the lowest-common-multiple and checking each function upon wakeup 
> > which would cause it to recheck needlessly often when using two speeds that 
> > don't cleanly divide, or by dynamically calculating the time until the next 
> > interrupt would occur (current implementation, I believe) which causes more 
> > delayed jitter which is expounded by the sleeping function's inherent 
> > innacuracy.

Yes, that is the current implementation.

> 
> We should somewhere add a test of the timer accuracy.

That would certainly be welcome.

Peter