I have observed behavior that MAY be explained by select() (or poll()) used with a timeout value returning when the system clock is changed by ntpd (or maybe the date utility).

I call select() with a timeout and when the system clock is updated (ntpd started) it appears that the select returns as if it timed out.

Anyone know whether is the really the behavior of select()?
I am using a 2.4 Linux kernel.

d71

I can't find such behaviour in the code. Do you have a chance to see what's the struct timeval passed to select value after return? In Linux it returns the time left to the actual timeout.

No, I have not done any further experimentation yet.

I too looked through kernel code and found that it appears that possibly all waiting processes/tasks are awakened when the system time is modified. I say possibly because there are some conditions on awakening the processes/tasks and I don't know whether they apply.

Also, even if the process is awakened, I don't know what the behavior of the process is after being awakened, i.e., does the system call in which it is waiting return immediately or might it go back to waiting.

In this case the changing of the clock a (I think) large time forward may cause the time limit to appear to have been exceeded, i.e. timed out. However, we appear to see this expiration when the clock is modified by NTP even when the modification is far less than the timeout value.

The return value in the struct timeval might shed some light on that.

Thanks!

Large change of time value is another story (through I have not managed to wake up my select() when I made such an experiment, but it's 2.6), but with short changes there's no reason to wake them.