Date: Sun, 18 May 1997 14:10:45 +0800 From: Peter Wemm <peter@spinner.DIALix.COM> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen usleep.c Message-ID: <199705180610.OAA04447@spinner.DIALix.COM> In-Reply-To: Your message of "Sun, 18 May 1997 13:01:28 %2B1000." <199705180301.NAA20270@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > Modified files: > lib/libc/gen usleep.c > Log: > if nanosleep returns too early, loop. usleep() does not have a return > value, it appears as though the semantics of usleep are that it doesn't > return early. (only in the nanosleep code - the setitimer code does this > already) > > Where do those semantics appear? The old behaviour was to return > early. The man page said otherwise, but so does the BSD4.4-Lite man ^^^^^ Are you sure of that? Both sleep() and usleep() do a 'while (!ringring) sigpause(...)'.. To my reading, it won't return early ever... The sleep(3) implementation was the same, it didn't ever return early either as far as I can see. There's no way out except for a longjump from within some other signal handler. My observations of the svr4 libc suggest that it uses alarm() and a sigpause() once and doesn't sit in a while loop.. So, sleep(3) will return early. The svr4 version of usleep() (presumably based on sunos 4.x code) appears to use setitimer and do the same while (!finished) sigpause(..). > page for sleep(3). usleep.3 is a clone of sleep.3 in in BSD4.4-Lite. > Someone fixed the worst bugs in sleep.3 but didn't change usleep.3. > The actual behaviour hasn't changed since 386BSD. It seems to me that somebody cloned the usleep(3) code to replace sleep(3), presumably this was csrg, but I couldn't guess how far back. > Bruce Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705180610.OAA04447>