Re: Generic battery interface

[Valdis.Kletnieks@vt.edu]

On Sun, 30 Jul 2006 14:48:07 +0300, Shem Multinymous said:
> On 7/30/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> 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: pgpXmewXcH9CD.pgp
Description: PGP signature