> Rogier Wolff wrote:
> > Clock interrupts + + + + +
> > App is waken up: * * * *
> > app calls usleep (9000) ^ ^ ^ ^
> >
> > it will only sleep for 2ms before getting woken. And the manual states
> > that the sleep will be -=* at least *=- the number of microseconds
> > requested, and that you should always be prepared to be woken a little
> > later due to scheduling overhead or other tasks running.
>
> I hate to cite it, but people should read the manpage before they
> implement something. The manpage of select is quite clear about what the
> timeout means:
>
> "timeout is an upper bound on the amount of time elapsed
> before select returns."
>
> Thus select should return *before* timeout expires. Well, it doesn't
sorry, but this way of reading makes no sense! in your reading it would
be perfectly fine if select would return immediately, and it would be wrong
if returning some usec after timeout.
and if you directly consider the need of delays/sleeps, upper bounds make
no sense and you can't guarantee them -- but sleeping _at_least_ some
period of time is perfectly reasonable and it's just implemented this way.
select either waits until the status changes, _or_ it will time out.
`timeout' is an upper bound how long to _wait_ before timing out and returning.
but select obviously can't guarantee that it will return before `timeout'
is over.
> need to return if the process is descheduled, or if it takes more time
> to calculate the result than timeout was set to, but IMHO select should
> not wait at all for timeout between 0 and 10 ms, wait for up to 10 ms
> for a timeout between 10 and 20 ms*... or even better, incorporate the
> microsecond patch which allows a much finer grain for requested
> timeouts, at the cost of a less accurate clock (or uses the processor's
> timer register if available).
>
> *) more correct would be to look if there is a timer interrupt before
> the expire time, and schedule the wakeup at that timer interrupt. Thus
> if the next timer interrupt is due in 2 ms, a 2 ms timeout is ok to
> sleep for.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/