On Wed, 14 Oct 2009, Ico Doornekamp wrote:
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.
You missed the point.
The BSD man page is emphatic that an application can change the definition
of FD_SETSIZE and obtain defined behavior. It states how to do it.
There is nothing in the Linux man page which says that you can (or can
not) change the definition of FD_SETSIZE.
If, as some have said, this is a glibc issue on Linux, then some means
should be possible for the application to change FD_SETSIZE.
If, on the hand, it is a kernel restriction, only a change to the kernel
will fix it.
I do not know which of these is is; nor do I know the necessarily
procedures either way. This is a research task for someone else.
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.
Do you meant to say that Linux is hopelessly inferior to BSD and will
never be as good as BSD?
If not, then what are you saying?
BSD demonstrably has a capability to make select() work with all valid
fds. Does Linux have that capability or not?
I don't know; and if you don't know you should find out instead of arguing
with me.
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.
I see nothing in Linux's documentation that says that. There is no listed
bug that says "select() on Linux can't ever handle fds greater than 1024."
The only reference to FD_SETSIZE is that it is the limit to the FD_SET and
FD_CLEAR macros. There is nothing whatsoever stating whether that limit
can be changed, nor if the kernel would respect that changed limit.
Once again, instead of arguing with me, you should talk to someone who
knows either way.
Whatever the cause of this limitation: all I'm saying this is a *well
known* limitation.
So what?
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.
Every kernel developer?? Or just every 18-year-old who thought that he
was a kernel developer?
poll() can be a very poor interface, both from the application and the
kernel's point of view. poll() does not scale at all for large numbers of
events. Yes, doing select() well requires an understanding of how to work
effectively with bitmasks; a topic that is generally deferred for advanced
CS classes. Some people actually have mastered that concept.
More to the point: NOWHERE in the Linux man page for either poll() or
select() is select() declared to be arcane or "has problems". The Linux
man pages are not at all shy about making such declarations.
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 ?
The discussion came up with multiple courses of action:
[1] Give up.
[2] Determine that the Linux kernel doesn't have any wired knowledge of
the length of an fd_set. Then:
[2a] Determine how to redefine FD_SETSIZE in an application so
that the fd_set struct and FD_SET/FD_CLEAR macros are defined to
be a size large enough to accomodate any possible fd.
[2b] Fix glibc to redefine FD_SETSIZE so that the fd_set struct
and FD_SET/FD_CLEAR macros are defined to be a size large enough
to accomodate any possible fd.
[3] Determine that the Linux kernel has wired knowledge of the length of
an fd_set. Change that wired knowledge so that the kernel can handle a
fd_set of size large enough to accomodate any possible fd. Then do either
[2a] or [2b].
[4] Kludge tcp_open() in c-client so that when it gets a socket it will
get one in the range.
[5] Kludge Apache so that it cleans up its fds and libraries (not just
c-client) called by do not hit the limit.
[6] Change c-client to use poll().
[7] Use some other library that still has a developer.
If I were you, I would look into [2a], and would seek authoritative
information from a real Linux kernel developer on the issues in [2] and
[3].
-- 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
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
