On Tue, Aug 01, 2006 at 01:45:27AM +0300, Shem Multinymous wrote:
>>And keeping the latest readout for each app isn't that heavy. After all
>>we already have to keep track of the timeouts for each app.
>The timeouts bookkeeping will normally be done by some infrastructure,
>and can often be (in principle) be optimized to less than on value per
>app. Also, it's just one timestamp. By contrast, what you're asking
>for requires explicit handling by every driver, and the attribute
>value may take significant amount of storage -- per app.
If you are that concerned about storage why the complex timeout model?
That can easily handled in userspace with just the blocking and
> The app can do this itself by polling and checking the value, with a
> (not too) small value of dupeq.min_wait. In the case of a
> polling-based data source, the resulting hardware queries and timer
> interrupts are exactly the same as an in-kernel implementation which
> does the polling and comparions itself. If the data source is
> event-based then the comparison in userspace does have a drawback: the
> comparions are done just dupeq.min_wait apart even if the event rate
> happens to be higher. Can you think of a case where this matters?
The problem I see is the overhead. Visual feedback that feels
instantaneous would require dupeq.min_wait<50ms. And as far as I can
tell each read requires to switch from userspace to kernelspace and
back. When I look at the available variables I can easily imagine
applications that would read >10 variables. That's not something I would
want to do that often.