Date: Mon, 4 Aug 1997 09:46:13 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: edmond@shaman.lycaeum.org (Andrew N. Edmond) Cc: terry@lambert.org, fbsdlist@federation.addy.com, questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Too many open files in System! Message-ID: <199708041646.JAA04188@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.96.970803235437.1586B-100000@necropolis.org> from "Andrew N. Edmond" at Aug 3, 97 11:58:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Thanks for the great answer Terry, Cliff and ahem... Jordan :-) > > In any case, the sysctl settings worked great, messed with login.conf some > as well, and the #define FD_SETSIZE works great.... except with... > mit-pthreads. > > mit-pthreads is puking everytime I try to set the FD_SETSIZE (yes, before > <sys/types.h>), and even when I go into the pthreads source and try to > change that version of FD_SETSIZE, it's still puking at a value of 1024. > At 256 it works fine. Any ideas? Are you setting it before including *any* headers? There was once a misbegotten idea that headers should include all the other headers they require. This could get <sys/types.h> in before you think it is in... Also, check out the stdio stuff in the pthreads library; there was a stdio limitation that had this problem (I know, you are using sockets, so they are raw fd's, instead of FILE pointers...). Finally, the way libpthreads does call conversion is to make the fd non-blocking and trade a blocking operation on a blocking fd for a blocking operation on a non-blocking fd, plus a thread context switch. This is one of the three common ways to implement threads. Because of this, there is a table of open fd's maintained internally by the threads library. I *thought* that it was dynamically sized, but I haven't had need to look for it, since I haven't done anything that needed that many simultaneous connections in a threads environment (I generally use shared process context environments for these things to allow me to beeter compete for CPU quanta against other processes on the system). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708041646.JAA04188>