[AD] Using HPET in Linux/Unix? |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: [AD] Using HPET in Linux/Unix?
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Thu, 25 Aug 2005 18:51:49 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=FQ0lhxssqdRECfGYFj1v0p0CX9Ui3Zv/krDtY57nx46+MMs3Aez84YVjw3LurTqXM4GKywtyn5+hsF/yVT9bh0e9NhFeqYJhJ2QeNeY/onofozmFFJNCvpOCHq08rtu402JeNrOXfat1z/pAFDYL4yU/5VPvQVq0D0luf0grwqU=
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 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.
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.