Bug 31504
| Summary: | nanosleep() strange behavior | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Vladimir Birjukov <prg51> |
| Component: | i386 | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.4-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
In message <200110260649.f9Q6ntN98813@freefall.freebsd.org>, Vladimir Birjukov writes: >In picprog program (ports/devel/picprog), which work nice in FreeBSD 4.3-RELEASE >after become STABLE lost functioning. Because such fragment > ioctl (fd, TIOCMBIS, &picport::rts_bit); // clock up > delay_100 (); > ioctl (fd, TIOCMBIC, &picport::rts_bit); // clock down >where delay_100 is: > static const struct timespec ns100 = { 0, 100 }; > nanosleep (&ns100, 0); >Makes 10 milliseconds pulse instead 0.1 mikrosecond nanosleep() has a resolution if 1/hz. By default your hz is 100 which is where your 10 msec comes from. You can increas hz to 1000 with no problems, 10000 works as well on some hardware, but there is a bug in the tty c_cc[VTIME] handling which gets increasingly bothersome for increasing hz -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. State Changed From-To: open->closed As PHK explained, the granularity of nanosleep() is tied to the frequency of clock interrupts, and this is not likely to change. POSIX says clearly: # The suspension time may be longer than requested because the argument # value is rounded up to an integer multiple of the sleep resolution or # because of the scheduling of other activity by the system. There is no portable mechanism to determine the precise value of the sleep resolution. The Rationale suggests that it should be less than one second, but I can find no normative text even defining the term. |
In picprog program (ports/devel/picprog), which work nice in FreeBSD 4.3-RELEASE after become STABLE lost functioning. Because such fragment ioctl (fd, TIOCMBIS, &picport::rts_bit); // clock up delay_100 (); ioctl (fd, TIOCMBIC, &picport::rts_bit); // clock down where delay_100 is: static const struct timespec ns100 = { 0, 100 }; nanosleep (&ns100, 0); Makes 10 milliseconds pulse instead 0.1 mikrosecond And I Think some strange behavior in console application may have the same source, as this described. How-To-Repeat: This code should not work one second. #include <time.h> int main() { int i; static const struct timespec ns100 = { 0, 100 }; for (i=0; i<100; i++) nanosleep (&ns100, 0); return 0; }