Re: Can't sleep less than 20 ms

Steve Underwood (steveu@netpage.com.hk)
Mon, 05 Jul 1999 14:40:14 +0000


Johan Myréen wrote:

> Harald Koenig wrote:
>
> > > 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

Yes, and some people think before they write. This is not a real time system.
There are _no_ upper bounds on _any_ execution times. Scheduling is totally
"best efforts" based.

> > > 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

The wording is sloppy. About 2 seconds thinking should tell you the time-out is
actually the upper bound on _waiting_ for some I/O. The actual point of return
could be any time later, depending on how busy the machine is.

> > 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.
>
> I think the manual page wording makes perfect sense. The kernel is serving
> the application, and it is in the interest of the application to get a
> guarantee on the upper bound of the timeout. It is of course in the
> interest of the _kernel_, whose task is to sensibly allocate the host's
> resources to all processes, to make the timeout as long as possible (but
> within bounds of the requested timeout.)

Garbage. Think for 2 more seconds. There is no upper bound on the workload you
can put on this machine, and the processes are fighting equally for resources
(even nice doesn't change that very much). It doesn't even have any pseudo
real-time features. To achieve what you want for arbitrary processes would
require an infinitely fast machine. It ridiculous.

> If we make 'timeout' the lower bound, then by the same logic it would be
> perfectly fine for a conforming select to never return.

Steve

-
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/