Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!iuvax!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!bader+ From: bader+@andrew.cmu.edu (Miles Bader) Newsgroups: comp.sys.amiga.tech Subject: Re: Timer question Message-ID: Date: 7 Jan 89 04:41:16 GMT References: <427@tekn01.chalmers.se> <3210@amiga.UUCP> <3137@sugar.uu.net> <5584@cbmvax.UUCP> <3209@sugar.uu.net>, <5635@cbmvax.UUCP> Organization: Carnegie Mellon Lines: 27 In-Reply-To: <5635@cbmvax.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom MKT) writes: > Ideally it could be done as a handler with clients added such that each > client's timer variable can be updated. Ooh, but how does that work given > each client will want different precision? Perhaps a "minimum precision" > must be set, and all client precisions are a multiple of this? This could > mean a LOT of interrupts for the main handler. Solutions? How exactly do the hardware timers work? Can you read the hardware count directly? If so, you'd just set the interrupt (at which point I assume the timer resets) interval relatively large, and when then a client asks the library for the "current time", return the hardware count adjusted appropiately, plus the high order bits which get bumped every timer interrupt. If not, then I guess you'd have to set the timer interrupt interval to whatever the most finest granularity some client requests in advance (but that's not a big deal, as ANY program using the timer has to do it). So, I don't see how a library keeping track of the time for a bunch of clients would be any more complicated than a single program hogging it... [Why they talk of maintaining separate counters for each program? Just have each program ask for the time when it needs it!] -Miles