Date: Mon, 27 Dec 1999 17:40:02 -0800 (PST) From: Mikhail Teterin <mi@kot.ne.mediaone.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/13644 Message-ID: <199912280140.RAA72190@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/13644; it has been noted by GNATS.
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
Date: Mon, 27 Dec 1999 20:38:58 -0500 (EST)
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?199912280140.RAA72190>