Date: Tue, 28 May 1996 13:10:02 -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: <199605282010.NAA11719@phaeton.artisoft.com> In-Reply-To: <199605281859.OAA19612@exalt.x.org> from "Kaleb S. KEITHLEY" at May 28, 96 02:59:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. Trace it with the SunOS 4.1.3 trace instead. It will say "select". I suspect that there are different systent[] tables in use, just like the ABI support in FreeBSD uses. > > 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. Sorry. will *USE* a struct timeval argument to the best of the systems ability (system clock frequency), not *TRUNCATE* it to what it feels like (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. You were using SVR4's implementation of select(3) on top of poll(2) as an argument for poll(2), with a presumption that the resoloution would move to 1ms (which is still too damn large for most useful things, like click-timing or mouse-motion accelerators). The select(3) argument is inherently flawed because the SVR4 systems that use the approach you suggest are in violation of their own specifications. "Here is a bad practice example of why this is an acceptable practice" just doesn't fly. > 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. The set size limitations are a result of the FD_SETSIZE, an advisory value, being used as a copyin limit in kernel space. In point of fact, the limit is derivable from the nfds argument to select. Use a -current kernel instead of a 2.1.0R kernel and I believe this has been fixed for you. The poll(2) interface does not save the copyin because it provides an array address. User space array contents are not directly addressable from kernel space, so you are still stuck. The only overhead it saves is the mask reset overhead in user space, which it trades for bit clearing overhead in kernel space. Big deal. 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?199605282010.NAA11719>