* [PATCH][3/4] poll()/select() timeout behavior
@ 2004-02-20 21:03 Bill Rugolsky Jr.
2004-02-20 21:55 ` Richard B. Johnson
0 siblings, 1 reply; 2+ messages in thread
From: Bill Rugolsky Jr. @ 2004-02-20 21:03 UTC (permalink / raw)
To: torvalds, akpm; +Cc: linux-kernel, brugolsky
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
--- 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;
}
}
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH][3/4] poll()/select() timeout behavior
2004-02-20 21:03 [PATCH][3/4] poll()/select() timeout behavior Bill Rugolsky Jr.
@ 2004-02-20 21:55 ` Richard B. Johnson
0 siblings, 0 replies; 2+ messages in thread
From: Richard B. Johnson @ 2004-02-20 21:55 UTC (permalink / raw)
To: Bill Rugolsky Jr.; +Cc: torvalds, akpm, linux-kernel
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-02-20 21:55 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-20 21:03 [PATCH][3/4] poll()/select() timeout behavior Bill Rugolsky Jr.
2004-02-20 21:55 ` Richard B. Johnson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®