Re: [rfc] aio-core for 2.5.29 (Re: async-io API registration for 2.5.29)

[Charles 'Buck' Krasic]

Andrea Arcangeli <[e-mail]> writes:

> are you sure this is a good idea? this adds an implicit gettimeofday
> (thought no entry/exit kernel) to every getevents syscall with a
> "when" specificed, so the user may now need to do gettimeofday both
> externally and internally to use the previous "timeout" feature (given
> the kernel can delay only of a timeout, so the kernel has to calculate
> the timeout internally now). I guess I prefer the previous version that
> had the "timeout" information instead of "when". Also many soft
> multimedia only expect the timeout to take "timeout", and if a frame
> skips they'll just slowdown the frame rate, so they won't be real time
> but you'll see something on the screen/audio. Otherwise they can keep
> timing out endlessy if they cannot keep up with the stream, and they
> will show nothing rather than showing a low frame rate.

I disagree.  If for some reason the multimedia player can not keep up,
there will be corresponding changes to subsequent requested timeouts.
For example, the pattern of future timeouts will reflect the new lower
frame rate (e.g. timeout after 1/15 s instead of 1/30 s).  (BTW: I've
written adaptive media players, so I'm speaking from experience).

How repulsive would it be to add a boolean parameter that indicates
whether the supplied timeout value is relative or absolute?

-- Buck