Re: [AD] Using HPET in Linux/Unix?

[Elias Pschernig <elias@xxxxxxxxxx>]

On Thu, 2005-08-25 at 18:51 -0700, Chris wrote:
> I've been pondering the ability to use HPET (High-Precision Event Timers) for 
> Allegro's timer support in Linux (or general Unix, if available). The API 
> seems to be simple enough.. a command to register a timer, one to stop the 
> timer, and one to dynamicly change options of a timer. Besides potentially 
> being more precise than threads allow, it uses a proper timer system, instead 
> of one emulated with threads. A page that Thomas Fjellstrom found on the 
> subject is here:
> 
> http://www.linuxhq.com/kernel/v2.6/8/Documentation/hpet.txt

I don't understand what the example there does, but sounds useful.
Basically, it does just what Allegro timers do, right? Something I
wonder is if it can be used by user programs..

> I know this won't make it in for 4.2.0, but it could potentially be included 
> in 4.2.1 since adding symbols won't break backwards compatibility with Unix 
> shared libs.

We also have forward compatiblity according to abi._tx. But it could fo
into 4.3.x.

> I was curious if anyone's thought of this, or if you think it'd be too 
> dangerous to switch away from a multi-threaded timer model. The X 
> input/graphics stuff (which would be better off in another thread since it 
> needs proper mutex locks) is run in a bg manager system which can continue to 
> use a thread, but user timers and sound mixing (which can be moved into a 
> user timer) should be able to switch to it fine and benefit from increased 
> accuracy.

Shouldn't it be done as a separate timer driver? In Windows we also have
multiple timer drivers. And I doubt HPET would be available on all
systems, so in case it is not available, or the user possibly has no
access rights, the threaded one would be used.

On the subject of timers, I assume the al_get_ticks() in 4.3.x will get
rid of 95% (or more) of the use of timers in current Allegro programs,
since usually all they do is incrementing some frame counter :)

-- 
Elias Pschernig