From owner-freebsd-hackers Tue May 28 12:35:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA23897 for hackers-outgoing; Tue, 28 May 1996 12:35:41 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA23884 for ; Tue, 28 May 1996 12:35:39 -0700 (PDT) Received: from expo.x.org (expo.x.org [198.112.45.11]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id MAA07392 for ; Tue, 28 May 1996 12:02:41 -0700 Received: from exalt.x.org by expo.x.org id AA23371; Tue, 28 May 96 14:59:47 -0400 Received: from localhost by exalt.x.org id OAA19612; Tue, 28 May 1996 14:59:46 -0400 Message-Id: <199605281859.OAA19612@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.freebsd.org Subject: Re: Forgiving select() call. In-Reply-To: Your message of Tue, 28 May 1996 10:43:29 EST. <199605281743.KAA11388@phaeton.artisoft.com> Organization: X Consortium Date: Tue, 28 May 1996 14:59:45 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > > Any thoughts on writing a poll() which allows a variable number of bits > > > > > passed in the fd_set (or new) structure to get around FD_SETSIZE limits > > > > > > > > Poll is (finally) specified in Spec1170 and it doesn't use bits in an > > > > fd_set. If you want a system call that does this, don't call it poll. > > > > > > And if you want a poll() system call that has beeter than 10ms timer > > > resoloution, don't call it poll(). The select() call *does* have > > > some advantages over poll(), still. > > > > Yup, well, seems like we've had this talk before. The spec for poll > > allows delays with 1ms resolution. You can argue all you want about > > how the SVR4 poll implementation is inherently flawed to yield the > > actual 10ms granularity you cite, and you're no doubt correct, but > > that doesn't mean that a FreeBSD implementation need be similarly > > flawed. > > SVID III states that the expiry resoloution can be at the system clock > update frequency -- which is the frequency at which the RAM copy of > the system clock is updated from the real system clock to bypass the > need for real (potentially slow) clock access on each call to retrieve > the value of the system clock. > > On Solaris, the system clock update frequency is 10ms (100Hz). I > don't know of *any* UNIX implementation where the standard Hz is > set to 1000, which is what it would take to support your 1ms > resolution. Yeah, but who gives a rats ass. This is FreeBSD-hackers. We aint gonna fix Solaris here. As I've said repeatedly, there's no reason why a FreeBSD implementation would need to be similarly brain damaged. > In any case, I want 200uS resoloution. Select(2) on SunOS followed > by a call to gettimeofday() on a SPARCStation 1+ has a 4uS potential > resoloution, assuming non-full use of process quantum (which is an > entirely different problem). A polltv function could accomplish the same thing, and do it without the overhead of FD_ZERO/FD_SET, or the overhead of copying one or more fd_sets into the kernel address space. It wouldn't take much effort to contrive a program that poll would be vastly more efficient than select. > > And, FWIW, SVR4 select(3) is implemented using poll(2), so select on > > SVR4, in and of itself, isn't going to have any better granularity > > than poll. > > When Solaris 2.1 introduces SunOS 4.x binary compatability, I (within > a day of receiving it) reported that it would not run statically > linked SunOS 4.x binaries which used the select(2) (and a couple of > other) system calls. > > Sun corrected this in Solaris 2.3. There is no select(2) in Solaris 2.4 or 2.5. I statically linked a trivial program that uses select on SunOS 4.1.3 and trussed it on Solaris 2.4 -- it calls poll. Are you talking about a program that used the syscall interface to call select rather than the C library? I can easily imagine Sun getting that wrong in the early days of Solaris. But guess what, trussing a program that uses syscall(SYS_select, ...) on Solaris 2.4 shows that it's *still* calling poll. > You are correct that SVR4 as shipped by Novell/SCO still implement > select() as select(3) instead of select(2) As does Solaris, UXP, and NEWS/OS and MP/RAS. Of the SVR4 systems I have only IRIX has select(2). > This, however, places their operating system in violation of SVID III, > which specificies select(RT) will take a timeval struct argument. What are you talking about? select(3) takes a struct timeval argument. > We can make this case, because SVID III getitimer(RT) and setitimer(RT) > specifies the use of the system clock frequency, whereas gettimeofday(RT) > specifies system clock update frequency. > > > Technically, then, SVR4 derived OS's which implement select() as > select(3) instead of select(2) have converted it from system clock to > system clock update. > > This is in violation of SVID III select(RT) definition. Whether it is or not seems of little concern to the readers of freebsd-hackers. > So you may argue that certain OS's implement select(3) all you want, > but those OS's are not System V OS's by virtue of their failure to > comply with SVID III. But Terry, we don't care. > Military contractors, listen up: SVR4 is not SVID compliant; DFARS > and AFCAC requisition guidelines specify SVID. Be prepared to have > to provide sole-source justification if you recommend SCO/Novell SVR4 > instead of Solaris 2.x (x>=3). > > 8-P. But Terry, we don't care. > > At the other end of the spectrum poll doesn't allow for arbitrarily > > long delays, i.e. longer than MAXINT ms. A new API is needed that > > takes, e.g. a struct timeval instead of an int to request large delays. > > We could call it select(2). 8-). Not if it has a poll-like interface instead of fd_sets. Select just isn't optimal for dealing with small sets of file descriptors, particularly when the file descriptors are large numbers (which may be a pathological case.) Okay, even in the worst case, FD_SETSIZE is pretty small on FreeBSD -- only 256 bits. Is this a compromize for speed, or because of a limited kernel stack space? Most other systems have larger default values. -- Kaleb KEITHLEY