From owner-freebsd-bugs Sun Aug 10 04:30:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA17174 for bugs-outgoing; Sun, 10 Aug 1997 04:30:03 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA17164; Sun, 10 Aug 1997 04:30:01 -0700 (PDT) Date: Sun, 10 Aug 1997 04:30:01 -0700 (PDT) Message-Id: <199708101130.EAA17164@hub.freebsd.org> To: freebsd-bugs Cc: From: Bruce Evans Subject: Re: bin/4259: sleep(3) broken for large values Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4259; it has been noted by GNATS. From: Bruce Evans 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