Re: problem/bug/limitation in uw-client-library

* 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 ?