Date: Tue, 28 May 1996 15:36: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: <199605282236.PAA12003@phaeton.artisoft.com> In-Reply-To: <199605282116.RAA19947@exalt.x.org> from "Kaleb S. KEITHLEY" at May 28, 96 05:16:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. Trace it on a SunOS 4.1.3 *box*. Note "#define SYS_select 93" in /usr/include/syscall.h on your 4.1.3 box. Note "#define SYS_poll 153" in /usr/include/syscall.h on your 4.1.3 box. Note "man select" returning "select(2)". Note "man poll" returning "poll(2)". Note "man 3 select" returning "not found". Select in 4.1.3 is a system call. A statically linked 4.1.3 binary will trap the select(2) stub through trap entry 93. A 4.1.3 binary calling "syscall(SYS_select, nfds, rfds, wfds, xfds, tvp)" will trap through entry 93. A Solaris "5.x" binary calling through the manifest address for SYS_select via "syscall(93, nfds, rfds, wfds, xfds, tvp)" will trap through entry 93. That's the way it is. If truss lies to you... too bad. > 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). Poll's merits are on the basis of an improper implementation of select. > > 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. Bunk. If the kernel uses FD_SETSIZE at all, it's broken. Poll has limits on the number of fd's as well; they are the same limits as select imposes (signed int). > > 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. Well, that's the fix. It's not like 2.1R would suddenly grow a poll() call if you fixed it -- it would go into -current, if it went in, and you'd still have your "release-du-hour" problem staring you in the face. > 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. ??? I don't see this... unless the area is mmapped, it doesn't have a kernel PTD. > > 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. I can make the same argument about traversing the array; the original complaint about ~250 was an IRC server that was running over 256 entries and using an old kernel before the FD_SETSIZE was ripped out of the kernel space. For 250 fd's, traversing a 250 entry array in kernel space in order to do the job is at least as annoying. For something only doing one or two descriptors, it doesn't *need* the minimalized overhead that something that has to be responsive to 250 clients needs. 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?199605282236.PAA12003>