Date: Sun, 23 Jan 2000 20:26:15 -0500 (EST) From: Mikhail Teterin <mi@kot.ne.mediaone.net> To: Jason Evans <jasone@canonware.com> Cc: Mikhail Teterin <mi@kot.ne.mediaone.net>, David Schwartz <davids@webmaster.com>, bde@freebsd.org, hackers@freebsd.org Subject: Re: kern/13644 Message-ID: <200001240126.UAA44772@rtfm.newton> In-Reply-To: <20000123121055.F27689@sturm.canonware.com> from Jason Evans at "Jan 23, 2000 12:10:55 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans once stated:
=I thought Bruce was pretty clear when he explained that such upper
=bounds are not possible unless the operating system can make hard
=real-time guarantees.
His explanation contradicted ALL of the documentation I was able to
find, and he chose not to comment on the contradiction.
=FreeBSD is clearly not capable of hard real-time. If I remember
=correctly, neither are any of the operating systems from which you
=quoted man pages. That makes *all* of those man pages inaccurate.
In other words, we found a flow in the most (all?) Unix implementations?
Including FreeBSD. Alright.
=In fact, as explained in earlier email, the timeout is rounded up in
=order to be certain that the process isn't woken up too early.
I did not want to be dragged into discussing the implementation, which
is something I'm only beginning to learn. But, perhaps, it can be
rounded DOWN instead? An application written by the man-page will expect
to be waken up EARLY (like TCL's implementation of after(n)), but no
man-page hints at the possibility to be waken up LATE. And yes, it
should, of course, understand that it may not actually get to run
because of the scheduling issues.
=Our man page is wrong:
=
= If timeout is a non-nil pointer, it specifies a
= maximum interval to wait for the selection to complete.
=If you can come up with some better wording that you can convince a
=committer is accurate and comprehensible, you might consider pursuing
=this issue. That's the only direction I have any interest in following
=this discussion in, however.
That's very nice, thank you. How about re-opening the PR?
Peter Jeremy wrote:
=Please provide a test program and results from these other vendors
=demonstrating that their select() will return before the specified time
=limit in the absence of any other event.
Never claimed it will... All of the man pages say, it is possible,
though. They do NOT say it is possible to return AFTER. Of course, the
program may not get to actually run right then. Just like it may be
delayed returning from a printf()...
The test program is very simple -- one line of TCL:
time {after 20} 100
This will report how many microseconds did a select for 20 milliseconds
_really_ take -- an average over 100 attempts. On an idle DUAL processor
PentiumII-300, with 3.4-STABLE, the typical result is 29937 microseconds
per iteration. On SunOS tornado 5.5.1 Generic_103640-24 sun4m sparc
SUNW,SPARCstation-20 it is a little better: 28167 microseconds per
iteration. Similarly for Irix. The TCL's over-head can be measured by
something simple, like:
time {set a 5} 100
3 microseconds per iteration # On FreeBSD
16 microseconds per iteration # On SunOS
28 microseconds per iteration # On Irix 6.5
HOWEVER! The reason I brought up the other vendors, was not to
claim, their IMPLEMENTATION was better then FreeBSD's, but that their
DOCUMENTATION was the same as ours. Bruce was saying our man page is
broken. I wanted him, or someone else, to confirm that all those other
vendors are incorrect in their man pages too.
You are saying, the man-pages are correct (contradicting Bruce)...
=It's probably worthwhile adding a comment to select(2) similar to that
=in sleep(3), noting that "system activity may lengthen the sleep by an
=indeterminate amount."
-mi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001240126.UAA44772>