Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data

[Michael Lindner]

Thanks CW and DS for the prompt replies. However, although each
addressed the (flawed) example I included, neither addressed the
problem described in the text.

I wrote:
> > If select() is waiting for data to become available on a
> > TCP socket FD, and
> > data becomes available, it doesn't return until the next clock tick.

David Schwartz wrote:
>         This program doesn't demonstrate anything except that Linux's sleep time is
> granular. This shouldn't be news to anyone. If you don't force a reschedule,
> everything works the way it's supposed to:

The sample program you included doesn't show anything other
than that select() doesn't sleep at all if there's already
data available when select() starts. That was not my claim
either.

My problem is that if data is NOT available when select()
starts, but becomes available immediately afterwards, select()
doesn't wake up immediately, but sleeps for 1/100 second.
In other words, select doesn't wake up immediately when
data becomes available, but on the next clock tick. This is
not the experience I've had with any other OS I've used,
and is a source of great latency in my application. Since
I am passing data from one process to another, and that
data is generated as a result of data received via a select(),
the next delivery occurs a clock tick later, with the machine
mostly idle.

It can be argued that there's no law governing the latency of
select() waking up, and that my application is expecting
too much. Yet, it runs on other UNIXes and Windows, and I'd
like to be able to get the same high performance out of Linux.

P.S. Chris Wedgwood writes:
	"The time passed to slect is a _minimum_ "

but the man page for select says:
	"timeout  is  an  upper bound on the amount of time elapsed
       before select returns."

who is right?

--
Mike Lindner