Date: Sun, 10 Aug 1997 06:10:02 -0700 (PDT) From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-bugs Subject: Re: bin/4259: sleep(3) broken for large values Message-ID: <199708101310.GAA20244@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: j@uriah.heep.sax.de (J Wunsch) To: bde@zeta.org.au (Bruce Evans) Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/4259: sleep(3) broken for large values Date: Sun, 10 Aug 1997 14:26:40 +0200 As Bruce Evans wrote: > >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. Apparently not. It used to work. I've only noticed the problem since one of my perl child processes that's running as a daemon like for (;;) sleep; # wait until we are being killed suddenly started to eat up one CPU (out of a total of one :). > 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(). The quick&dirty fix was to limit sleep(3)'s argument to 100000000 seconds. At least, this constant needs to be explained in documentation (itimerfix(9), nanosleep(2), etc.), and to be visible in a public header file, as opposed to be `implicit knowledge' you can only gain by reading kernel sources. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708101310.GAA20244>