Ken Cross wrote:
My $0.02...
Mike Sweet wrote:
Sooo, my recommendations are as follows:
1. Provide a configure option (--with-maxfiles or similar)
to configure the upper limit you want to support in SAMBA.
2. Provide a smb.conf option to control the max number of
file descriptors.
There's currently a "max smbd processes" in 3.0. Would that suffice for
max number of fd's for winbindd?
It might; I'm not sure how winbindd and smbd are tied together
(I don't use it myself...)
3. Provide a definition on Solaris for FD_SETSIZE before
including <sys/select.h> so that the correct version of
select() is used.
It's not just Solaris - I think it's fairly universal. And it must be
defined before <sys/types.h>
It doesn't work on Linux or OSX, and of the systems in our (ESP's)
build farm (AIX, FreeBSD, HP-UX, IRIX, Linux, OSX, Solaris, and
Tru64) only Solaris uses a different select() function when dealing
with more than 1024 fd's.
In this case, we are only setting FD_SETSIZE to get the right version
of select, not to increase the size of fd_set. We could just #ifdef
__sun and define select to select_large_fdset, however that is only
appropriate for newer versions of Solaris (starting with 7 IIRC).
4. On startup, query the current FD limit and set it to the
smaller of the "maxfiles" definition, the max value
reported by the kernel, and the max value in smb.conf.
And call setrlimit with this value.
Right.
5. Allocate the fd_set buffers [(maxfiles + 7) / 8 bytes]
and replace all use of FD_ZERO with memset/bzero with
the correct size.
It currently (and correctly, IMO) computes the largest *actual* fd and
uses that.
If you have that info, great. In CUPS, we just memcpy() a common
input/output set to temporary ones (makes tracking FDs simpler...)
--
______________________________________________________________________
Michael Sweet, Easy Software Products [EMAIL PROTECTED]
Printing Software for UNIX http://www.easysw.com
