Krishna M Singh wrote:
We are using the multiple contexts (although not same as thread count
i.e. 10 Contexts for 3 threads).. Select call may be failing as the
default FD_SET_SIZE is 255 on most systems and thus in case u want to
handle 1000 sockets u need to increase the limit.. There is #def in
some Windows file.. chk that.. (Assuming u are running this on
Windows)...
This response is closest to the truth.
By default the "fd_set" type is a standard size on each platform. In
another post you indicated you are using Linux 2.6.xx, which I presume
is based one glibc 2.3.x.
Looking at the systems I have access too glibc 2.3.2 and glibc 2.3.6:
$ grep __FD_SETSIZE /usr/include/bits/*.h
/usr/include/bits/typesizes.h:#define __FD_SETSIZE 1024
This is the maximum number of fd's the "fd_set" type holds by default.
Maybe it would be possible to stop the crashes and override this with
some ugly stack paddings:
#defined EXTRA_FDS 500
char padd0[(EXTRA_FDS/8)+1];
fd_set fdread;
char padd1[(EXTRA_FDS/8)+1];
Maybe look at the comment in /usr/include/linux/posix_types.h for
informations.
It does not look like there is a compile time override to allow a lager
size. Maybe the kernel has a hard upper limit for select() too, but I
dont this is the case.
As Kyle also pointed out "ulimit -n 1500" would need to be addressed on
most standard Linux installed to get any usage beyond the default 1024
limit. Otherwise accept() = -1 (EMFILE).
You may look at poll() and epoll() as alternative event wake mechanisms
for IO with large numbers of fds in the working set.
HTH
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
