From owner-freebsd-hackers  Sun Jan 23 17:26:26 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.15.190])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7D50614C4F; Sun, 23 Jan 2000 17:26:22 -0800 (PST)
	(envelope-from mi@kot.ne.mediaone.net)
Received: from rtfm.newton (mi@rtfm.newton [10.10.0.1])
	by kot.ne.mediaone.net (8.9.3/8.9.1) with ESMTP id UAA06402;
	Sun, 23 Jan 2000 20:26:15 -0500 (EST)
From: Mikhail Teterin <mi@kot.ne.mediaone.net>
X-Relay-IP: 10.10.0.1
Received: (from mi@localhost)
	by rtfm.newton (8.9.3/8.9.3) id UAA44772;
	Sun, 23 Jan 2000 20:26:15 -0500 (EST)
	(envelope-from mi@kot.ne.mediaone.net)
Message-Id: <200001240126.UAA44772@rtfm.newton>
Subject: Re: kern/13644
In-Reply-To: <20000123121055.F27689@sturm.canonware.com> from Jason Evans at
 "Jan 23, 2000 12:10:55 pm"
To: Jason Evans <jasone@canonware.com>
Date: Sun, 23 Jan 2000 20:26:15 -0500 (EST)
Cc: Mikhail Teterin <mi@kot.ne.mediaone.net>,
	David Schwartz <davids@webmaster.com>, bde@freebsd.org,
	hackers@freebsd.org
X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
	 hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
	 y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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