On Tue, 13 Oct 2009, Ico Doornekamp wrote:
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 think that you may not have understood my answer. Let me summarize and
clarify it:
[1] In BSD, there is a well-defined way to build software with a larger
FD_SETSIZE. From the BSD man page:
Although the provision of getdtablesize(2) was intended to allow user
programs to be written independent of the kernel limit on the number of
open files, the dimension of a sufficiently large bit field for select
remains a problem. The default size FD_SETSIZE (currently 1024) is some-
what smaller than the current kernel limit to the number of open files.
However, in order to accommodate programs which might potentially use a
larger number of open files with select, it is possible to increase this
size within a program by providing a larger definition of FD_SETSIZE
before the inclusion of <sys/types.h>.
This seems to point out a clear, and simple, solution for BSD systems.
[2] The Linux man pages do not mention this possibility.
[3] A check of the Linux include files indicates that the BSD solution
doesn't work in glibc, and raises the possibility that the Linux kernel
itself has this limitation in the select() call.
[4] Someone, with more knowledge of Linux glibc and the Linux kernel than
I possess, would have to address this matter in greater detail. Perhaps
there is a way to redefine FD_SETSIZE in application programs and it will
all work. I don't know.
[5] If the Linux kernel itself has this limitation, then the only way for
it to work with sockets >= 1024 would be to rewrite the code to use poll()
instead of select(), something which entails other risks. Once again, the
question of whether or not a kernel limitation exists is something that I
can not answer.
I suspect this bug bites a lot of, people because uw-imap is the default
(and only?) IMAP implementation available in PHP.
I am sympathetic, but it is not my problem. Voluntarily, I answered a
question with the technical information that I know, in the hope that you
could use the information to arrive at a solution.
But how you solve the problem is none of my concern.
So, has this problem been discussed before among uw-imap developers, and
have any viable solutions been proposed yet ?
There are no UW IMAP developers. There have been none for a year and a
half. UW IMAP is a dead project, and (as with any dead project) software
rot is starting to set in.
If a paying Panda IMAP site has an issue (none have), I care; but it is
then addressed in Panda IMAP, not UW IMAP.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
