Greg Wooledge wrote: > L A Walsh wrote: > > I remember some implementations only wait till the clock reaches the > > new time in seconds -- meaning that the actual sleep time could be > > .001 seconds. > > If true, that would actually violate POSIX. The sleep time must be > "at least" as long as the operand. It may be longer, but never shorter. > > You might be remembering it wrong.
I also remember that at one time the Unix sleep was implemented by polling a second granularity clock register. If one was not lucky then polling just before the second turned, and then just after, would cause sleep to exit because the second had changed. A 1 second sleep was 0-1 seconds. Therefore if one required at least a 1 second sleep one would need to ask for at least 2 seconds or it was possible for there to be very little sleep at all. A sleep 2 might be 1-2 seconds. Of course sleeping for 300 would rarely care if it was actually 299 or 300 so longer sleeps were never a practical problem. I recall this as a historical Unix kernel limitation. I forget which versions now and am not in a position to do a search through the historical record to figure out which kernels did it that way. I never worked on any such running system but recall it from comments written at the time. I don't think it is true with any modern kernels. Or even with older ones such as the venerable HP-UX 10.20 from 1996! I think it would be difficult to impossible to find any running Unix-like system outside of a museum environment that still behaved that old way. And certainly any using the fractional second extension is past any need to worry about the problem. Because any such system with the problem would only handle to a granularity of integer seconds anyway. Bob
