* On 2009-10-13 Mark Crispin <[email protected]> wrote :
> The comments in posix_types.h are definitely worth reading, as they betray > more baby-computer thinking. Worse, there is a __kernel_fd_set definition > which implies that the Linux kernel is incapable of handling programs > which are compiled with larger definitions of FD_SET. > > Even more annoying, Linux has a #define for the maximum file descriptor > value -- NR_OPEN -- and there is no reason other than cranium-up-rectum > disease for FD_SETSIZE to be any other value. I do completely agree with all you write above, but unfortunately this does not solve the problem the original poster states: the combination uw-imap/linux/php/apache/whatevermore does not scale above 1024 open file descriptors (= a few hundred websites), and basically results in a broken and useless configuration. I suspect this bug bites a lot of, people because uw-imap is the default (and only?) IMAP implementation available in PHP. And because PHP happens to be used in a *lot* of web applications - not only for access to mail, but also for user and password authentication through IMAP - this bug causes a *lot* of applications to break when deployed in a somewhat larger environment. I fully understand your rant about linux being broken (although I guess glibc is at fault here, not the linux kernel), and I see you are trying to say this bug is not uw-imap's fault. On the other hand: however unreasonable and arcane, the linux-FD_SETSIZE is a well known and well documented limitation, not some obscure bug in the dark corners of the operating system, and it would suit a portable and widely deployed library like uw-imap well to play nice in larger-scale environments as well. So, has this problem been discussed before among uw-imap developers, and have any viable solutions been proposed yet ? -- :wq ^X^Cy^K^X^C^C^C^C _______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
