Date: Tue, 28 May 1996 17:16:53 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: <199605282116.RAA19947@exalt.x.org> In-Reply-To: Your message of Tue, 28 May 1996 13:10:02 EST. <199605282010.NAA11719@phaeton.artisoft.com>
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". Sorry Charlie. No workie. If it ever did. A nm dump on /usr/4lib/libc.so.1.8 says select is UNDEF. ldd on the same file shows a dependency on /usr/lib/libc.so.1. As far as I can tell, and as far as the native mode truss shows, it all comes down to poll. Ain't no select(2) system call in Solaris. > > I suspect that there are different systent[] tables in use, just > like the ABI support in FreeBSD uses. Anecdotal evidence is no evidence. > > > 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). All I've said is that poll(2) (and polltv(2)) have their merits. At no time have I suggested that select(2) should be replaced with a select(3) that's implemented with poll(2). > The select(3) argument is inherently flawed because the SVR4 systems > that use the approach you suggest are in violation of their own > specifications. What is it you think I'm suggesting? All I've said is that poll(2) (and polltv(2)) have their merits. At no time have I suggested that select(2) should be replaced with a select(3) that's implemented with poll(2). > "Here is a bad practice example of why this is an acceptable practice" > just doesn't fly. Huh? > > 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. As long as it's <= FD_SETSIZE. > Use a -current kernel instead of a 2.1.0R kernel and I > believe this has been fixed for you. Yeah, well, I bet there's a lot of things the release-du-hour kernel does. I already have one system I seem to compile on an hourly basis. I don't need another. > The poll(2) interface does not save the copyin because it provides > an array address. Are you having a similar debate with someone else? I never claimed that it avoided a copyin. I just said that in some (pathological) cases it stood a good chance of needing to copyin less. > User space array contents are not directly > addressable from kernel space, so you are still stuck. C'mon Terry, what are you saying? It has to be directly addressable in order for copyin/copyout to work. Half the 2.1R kernel still uses memcpy or bcopy instead of copyin/copyout. McKusick's new book explains how this works, quite eloquently I think. > 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. It turns into a big deal if I want to select for read, write, and except on file descriptor 254. That's a lot of copying for one file descriptor. Imagine what it'd be like if FD_SETSIZE was 1024 or 4096 like it is on a lot of systems. And using poll I don't have to do *any* of the bit twiddling in user space or in kernel space. -- Kaleb KEITHLEY
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605282116.RAA19947>