Date: Sun, 10 Aug 1997 04:30:01 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: bin/4259: sleep(3) broken for large values Message-ID: <199708101130.EAA17164@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/4259; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: FreeBSD-gnats-submit@FreeBSD.ORG, j@uriah.heep.sax.de Cc: Subject: Re: bin/4259: sleep(3) broken for large values Date: Sun, 10 Aug 1997 21:22:43 +1000 >sleep(3) is now broken for arguments > 100000000 seconds (threshold >found empirically); it returns immediately in this case. Among It's always been broken like that. Anything involving itimers is restricted to an interval of 10^8 seconds (see itimerfix()). The problem is more serious for sleep() than for setitimer() because sleep() "can't fail". Perhaps the error handling is sloppier than before - errors for signanosleep(2) are not checked for, and the remaining time is not set for EINVAL errors (I think it should only be set for EINTR errors as in Linux - setting it in other cases is a waste of time and can't be relied on by portable applications). Restricting the interval to 10^8 seconds avoids overflow problems (until 10^ seconds = about 3 years before time_t overflows :-). tv_usec's are signed longs in `struct timeval' and time_t's (which happen to be signed longs) in `struct timespec', so UINT_MAX is not representable on systems with normal 32-bit ints and longs. nanosleep(2) should split up the interval into pieces <= 10^8 seconds long and sleep(3) should split up the interval into pieces <= TIME_T_MAX long if it is implemented using nanosleep(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708101130.EAA17164>