Messages in this thread | | | Date | Fri, 20 Feb 2004 16:55:27 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: [PATCH][3/4] poll()/select() timeout behavior |
| |
On Fri, 20 Feb 2004, Bill Rugolsky Jr. wrote:
> This patch changes select() and poll() to not wait forever when a valid, > but large timeout value is supplied. The SUSv3 manual page for select(2) > states: > > "If the timeout argument specifies a timeout interval greater than the > implementation-defined maximum value, the maximum value shall be used as > the actual timeout value." > > Both select() and poll() have a well-defined mechanism to wait forever, > so there is no need for the existing behavior. > > Please apply. > > Bill Rugolsky
The "well-defined mechanism" to wait forever for poll() is to use ANY negative value as the timeout value. If you chose -1, that, currently is MAX_SCHEDULE_TIMEOUT on Linux 2.4.24. Don't your changes muck this up or is "<0" checked somewhere else?
> > --- linux/fs/select.c 2004-02-20 14:27:24.784616879 -0500 > +++ linux/fs/select.c 2004-02-20 14:27:28.264660774 -0500 > @@ -316,6 +316,8 @@ > if ((unsigned long) sec < (MAX_SCHEDULE_TIMEOUT-1) / HZ - 1) { > timeout = ROUND_UP(usec, 1000000/HZ); > timeout += sec * (unsigned long) HZ; > + } else { > + timeout = MAX_SCHEDULE_TIMEOUT-1; > } > } > > @@ -476,7 +478,7 @@ > if (seconds <= (MAX_SCHEDULE_TIMEOUT-2) / HZ - 1) > timeout += seconds*HZ; > else > - timeout = MAX_SCHEDULE_TIMEOUT; > + timeout = MAX_SCHEDULE_TIMEOUT-1; > } > } >
Cheers, Dick Johnson Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips). Note 96.31% of all statistics are fiction.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |