From nobody@FreeBSD.org  Thu Oct 25 23:49:55 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 56F3937B408
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 25 Oct 2001 23:49:55 -0700 (PDT)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.4/8.11.4) id f9Q6ntN98813;
	Thu, 25 Oct 2001 23:49:55 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200110260649.f9Q6ntN98813@freefall.freebsd.org>
Date: Thu, 25 Oct 2001 23:49:55 -0700 (PDT)
From: Vladimir Birjukov <prg51@morics.riga.post.lv>
To: freebsd-gnats-submit@FreeBSD.org
Subject: nanosleep() strange behavior
X-Send-Pr-Version: www-1.0

>Number:         31504
>Category:       i386
>Synopsis:       nanosleep() strange behavior
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 25 23:50:01 PDT 2001
>Closed-Date:    Fri Oct 26 08:21:00 PDT 2001
>Last-Modified:  Fri Oct 26 08:38:45 PDT 2001
>Originator:     Vladimir Birjukov
>Release:        4.4-STABLE
>Organization:
at Home
>Environment:
FreeBSD aizk02.aizk.post.lv 4.4-STABLE FreeBSD 4.4-STABLE #14: Tue Oct 23 12:59:46 EEST 2001     wl@aizk02.aizk.post.lv:/usr/src/sys/compile/PRG51  i386


>Description:
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;
}
>Fix:

>Release-Note:
>Audit-Trail:

From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: Vladimir Birjukov <prg51@morics.riga.post.lv>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: i386/31504: nanosleep() strange behavior 
Date: Fri, 26 Oct 2001 08:55:51 +0200

 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 
State-Changed-By: wollman 
State-Changed-When: Fri Oct 26 08:21:00 PDT 2001 
State-Changed-Why:  
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. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=31504 
>Unformatted:
