Messages in this thread | | | Date | Fri, 19 Jan 2001 21:30:45 -0500 | From | Michael Lindner <> | Subject | Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |