* On 2009-10-13 Mark Crispin <mrc...@panda.com> wrote :
> 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. I might not have. Please summarize and clarify. > Let me summarize and clarify it: Ah yes, thank you! > [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. I think I have understood these two pretty well. Like I said, the linux FD_SETSIZE limit is well known and well documented. From 'man select' : : Executing FD_CLR() or FD_SET() with a value of fd that is negative or is : equal to or larger than FD_SETSIZE will result in undefined behavior. That's linux. We're not talking BSD here. > [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. Yes, I think I understood this one as well. The linux (glibc) select() manual does say nothing about the solution you mention, because this is a peculiarity of the BSD select. We're not talking BSD here. > [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. Although I'd not bet my head, I'm pretty damn sure this will not work. Anyway, according to linux's select() documentation, it's not ment to work this way. > [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. Whatever the cause of this limitation: all I'm saying this is a *well known* limitation. The select() system call itself is considered arcane and has more probles besides this limitation, it's only there bacause it always has been. Every kernel developer will simply tell you not to use it and to take a look at poll() instead. >> 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. Yes, thank you for that. > But how you solve the problem is none of my concern. I realize that, and I'm not saying it is. I'm only observing a problem (the combination uw-imap/*linux*/php/apache/whatevermore does not scale above 1024 open file descriptors) and asking a question to work towards a possible solution. >> 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. I was not aware the project is not activily maintained. Probably my wrong for not looking this up elsewhere before asking anything on the mailing list involving the code ? > If a paying Panda IMAP site has an issue (none have), I care; but it is > then addressed in Panda IMAP, not UW IMAP. I never asked you to care, my only question was if this problem has been adressed in the past. Ico -- :wq ^X^Cy^K^X^C^C^C^C _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
