Date: Tue, 28 May 1996 14:59:45 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: Terry Lambert <terry@lambert.org> Cc: hackers@freefall.freebsd.org Subject: Re: Forgiving select() call. Message-ID: <199605281859.OAA19612@exalt.x.org> In-Reply-To: Your message of Tue, 28 May 1996 10:43:29 EST. <199605281743.KAA11388@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605281859.OAA19612>