From owner-freebsd-hackers Tue May 28 15:38:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA10160 for hackers-outgoing; Tue, 28 May 1996 15:38:16 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA10147 for ; Tue, 28 May 1996 15:38:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA12003; Tue, 28 May 1996 15:36:02 -0700 From: Terry Lambert Message-Id: <199605282236.PAA12003@phaeton.artisoft.com> Subject: Re: Forgiving select() call. To: kaleb@x.org (Kaleb S. KEITHLEY) Date: Tue, 28 May 1996 15:36:02 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: <199605282116.RAA19947@exalt.x.org> from "Kaleb S. KEITHLEY" at May 28, 96 05:16:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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.