Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Dec 1999 20:38:58 -0500 (EST)
From:      Mikhail Teterin <mi@kot.ne.mediaone.net>
To:        jasone@FreeBSD.org
Cc:        freebsd-bugs@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org, lawlopez@cisco.com, jseger@FreeBSD.org
Subject:   Re: kern/13644
Message-ID:  <199912280138.UAA77606@rtfm.newton>
In-Reply-To: <19991227204603.A28DF14BB7@hub.freebsd.org> from "jasone@FreeBSD.ORG" at "Dec 27, 1999 12:46:03 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
jasone@FreeBSD.ORG once stated:

=Synopsis: select(2) timer inaccurate, especially with -pthread
=
=State-Changed-From-To: open->closed
=State-Changed-By: jasone
=State-Changed-When: Mon Dec 27 12:39:03 PST 1999
=State-Changed-Why: 
=The kernel  implementation of  sleep() uses  tvtohz() to  calculate the
=number of ticks  that tsleep() should sleep. tvtohz() adds  one tick to
=allow  for the  possibility that  the current  tick is  almost expired.

=select() guarantees that it will sleep  at least as long as the timeout
=before returning an empty result (0).

This is NOT what the man page states:

	If timeout is a non-nil  pointer, it specifies a maximum
	interval to wait for the selection to complete.

=If the  number of ticks  passed to tsleep()  were reduced by  one, this
=guarantee would no longer be possible.
=
=This is not a bug; it is  an artifact of correct implementation. If you
=need higher resolution, use nanosleep().

In  particular, TCL's  after(n)  implementation relies  on this  fact...
People responsible for  the TCL port may need to  take a note... Because
in TCL 8.x's  unix/tclUnixEvent.c there is a  function Tcl_Sleep(ms) and
the comments in it say:

    /*
     * The only trick here is that select appears to return early
     * under some conditions, so we have to check to make sure that
     * the right amount of time really has elapsed.  If it's too
     * early, go back to sleep again.
     */


Please, consider reviewing this again without the implementation details
obstructing the view. :-)

	-mi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912280138.UAA77606>