Date: Tue, 28 May 1996 10:43:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kaleb@x.org (Kaleb S. KEITHLEY) Cc: terry@lambert.org, hackers@freefall.freebsd.org Subject: Re: Forgiving select() call. Message-ID: <199605281743.KAA11388@phaeton.artisoft.com> In-Reply-To: <199605280125.VAA17242@exalt.x.org> from "Kaleb S. KEITHLEY" at May 27, 96 09:25:48 pm
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. 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). > 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. You are correct that SVR4 as shipped by Novell/SCO still implement select() as select(3) instead of select(2) (as Solaris now does). This, however, places their operating system in violation of SVID III, which specificies select(RT) will take a timeval struct 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. 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. 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. > 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-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605281743.KAA11388>