> it is correct to place an upper limit on the timeout.
> From the single unix spec
> (http://www.opengroup.org/publications/catalog/t912.htm):
> Implementations may place limitations on the maximum timeout interval
> supported. On all implementations, the maximum timeout interval
> supported will be at least 31 days. If the timeout argument specifies
> a timeout interval greater than the implementation-dependent maximum
> value, the maximum value will be used as the actual timeout value.
> Implementations may also place limitations on the granularity of
> timeout intervals. If the requested timeout interval requires a
> finer granularity than the implementation supports, the actual
> timeout interval will be rounded up to the next supported value.
Note that this can impose an upper limit on HZ.
In particular, 2^32 jiffies is 31 days at 1603.5 Hz.
If you need an extra bit, 2^31 jiffies is 31 days at 801.8 Hz.
Thus, a 31-bit jiffies limit is not compatible with HZ=1024.
(I distinctly recall looking at the POSIX spec and seeing in the
definition of clock() that it must not wrap before 24 hours, which, if
clock_t is a 32-bit type, implies a maximum CLOCKS_PER_SEC of 49710.
Thus, the common CLOCKS_PER_SEC=1000000 violates this badly, as it
wraps in 1:11:34.967296. Unfortunately, I don't have a copy of POSIX.1
handy to check my memory.)
-- -Colin- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/