On Sun, 30 Jul 2006 14:48:07 +0300, Shem Multinymous said: > On 7/30/06, Valdis.Kletnieks@xxxxxx <Valdis.Kletnieks@xxxxxx> wrote: > > If the program says '100ms' because it knows it will need to do a GUI update > > then, and you block it for 5 seconds because that's when the next value > > update happens, the user is stuck looking at their gkrellm or whatever not > > doing anything at all for 4.9 seconds.... > Please read my detailed proposal, posted (and resivsed) later. OK, if you meant this one (that hadn't shown up here before I hit 'send'): On Sun, 30 Jul 2006 13:14:10 +0300, Shem Multinymous said: > Actually my solution was "any update but no sooner than N msecs". So > you might be getting a readout that's N-1 msecs old, which was > meanwhile cached by the driver. If you care about that, you need to > use interleave those polls with msleep()s; see my recent detailed > post. You'll still doing at most one msleep() per fetched readout, > regardless of how frequently the driver provides them. That has slightly different semantics indeed, and avoids the issue I was commenting about. A gkrellm-ish program can query every 100ms and get a cached value 49 times out of 50 for a value that's hardware-updated every 5 seconds, and all will be well (of course, there's room for some added optimization, but I suspect trying to add that will end up more expensive than just re-reading the same cached value, unless the kernel has a good way to pass back a good hint of when the next update will be...)
Attachment:
pgp5LIxdcjmHB.pgp
Description: PGP signature
