Date: Mon, 16 Nov 1998 21:16:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: bakul@torrentnet.com, tlambert@primenet.com, nate@mt.sri.com, hackers@FreeBSD.ORG Subject: Re: Supporting more than FD_SETSIZE fd's Message-ID: <199811162116.OAA03285@usr08.primenet.com> In-Reply-To: <199811112303.PAA02167@salsa.gv.tsc.tdk.com> from "Don Lewis" at Nov 11, 98 03:03:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811162116.OAA03285>