From owner-freebsd-hackers Mon Nov 16 13:16:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12115 for freebsd-hackers-outgoing; Mon, 16 Nov 1998 13:16:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12109 for ; Mon, 16 Nov 1998 13:16:57 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA00353; Mon, 16 Nov 1998 14:16:32 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd000324; Mon Nov 16 14:16:25 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA03285; Mon, 16 Nov 1998 14:16:24 -0700 (MST) From: Terry Lambert Message-Id: <199811162116.OAA03285@usr08.primenet.com> Subject: Re: Supporting more than FD_SETSIZE fd's To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Mon, 16 Nov 1998 21:16:23 +0000 (GMT) Cc: bakul@torrentnet.com, tlambert@primenet.com, nate@mt.sri.com, hackers@FreeBSD.ORG In-Reply-To: <199811112303.PAA02167@salsa.gv.tsc.tdk.com> from "Don Lewis" at Nov 11, 98 03:03:13 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You may not want to do this. Some implementations return may return > very large numbers from getdtablesize(), like INT_MAX. I've heard > bug reports about software that wants to close all fds other than > 0, 1, and 2 between a fork() and an exec(), and it does so by looping > over all the numbers from 3 to the return value from getdtablesize() > and executing close() on each. This is horribly slow if getdtablesize() > returns an unreasonably large number. Bash likes to open the highest numbered fd it can possibly open, and use that as the fd for running scripts. It does this to take the fd out of the probable collision domain. This used to panic FreeBSD after bash chased the dup2() tail until the system was out of kernel memory, before there were hard and soft limits on number of descriptors per process. Basically, bash is just being lazy, since it could wrapper explicit descriptor references, and move its magic descriptor out of the way, as necessary, instead of consuming descriptor table resources for no good reason. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message