On Thu, 15 Oct 2009, Ico wrote:
GNU/Linux
There is no such thing.
I don't care about Richard Stallman's megalomanic fantasies.
particulary the versions using glibc as the C library. Which
would be most if not all of the mainstream GNU/Linux distributions.
Nonsense.
The bug is in a C compiler include file. Many systems don't have the C
compiler include files installed, as they do not have the C compiler
installed.
Neither a compiler, nor its include files, are part of an operating
system.
The operating system does not care what that value is set to. It is not
an operating system constant or variable.
It simply defines the size of the default bitmap, generated by the
compiler, that is passed to a system call that takes the actual maximum
size as an argument.
A binary generated with a different bitmap size will work perfectly well
on any system...INCLUDING a system which does the fix to that include
file.
Suppose that there was a bug that caused the string routines to fail if
the string ended with ".nl". Would people in Holland accept being told
"don't use the .nl domain, use .com instead"?
Yes, that's a stupid example, but no more stupid than "don't use this
system call because there's a bug in the compiler include files that we
refuse to fix."
It is a simple, one line fix which anyone can make. It does not change
the effect of any system binaries. The only thing that it does is cause
binaries built with the fixed version to work with larger file descriptor
values. Those binaries can be ported to any other system and they will
work.
BSD and
We're not talking BSD here.
BSD serves as proof that it is technically possible to solve the problem,
because they did.
It has further been shown that it is technically possible to apply a
similar solution to Linux.
If you disagree, then the answer should be "don't use Linux, use BSD
instead."
Linux systems are perfectly capable of handling more than 1024 file
descriptors in the select() call.
No, Linux 'systems' are not. The linux *kernel* is. The 'system' as a
whole usually consist of a bit more then just a kernel, for example a C
library.
That is Richard Stallman's nonsense. It is to cover up the fact that he
was not competent enough to create an operating system when he announced
GNU nearly 30 years ago, and lacks such competence today.
The definition in question does not impact any system libraries. It only
impacts whatever applications and libraries use select(). By fixing the
include file defintion on the system where the application/library is
built, you fix the resulting binary on ALL systems that run that binary.
The problem is in glibc. A ONE LINE bugfix to two glibc include files
fixes that limitation.
I never denied this, did I ? It is just a bit unfortunate that the main
author and maintaner of glibc does not agree with you this is a feasible
fix:
http://sourceware.org/ml/libc-alpha/2003-05/msg00173.html
Ulrich Drepper's opinions no longer matter. Everybody is switching to
eglibc from Drepper's glibc, in part because Drepper refuses to maintain
glibc properly.
Funny details is that he recommends to use poll() instead.
His binary compatibility argument is bogus. It doesn't matter even if you
link an application with two libraries which were build with different
definitions. The first argument to the select() call defines the maximum
length of the fd_sets. The only thing that FD_SETSIZE does is ensure that
the compiler generates an fd_set that is long enough.
What it really comes down to is that Drepper didn't want to fix his bugs,
and instead wants everybody else to break their code to accomodate his
bugs.
There is an excellent reason why I did not use poll(); c-client to this
day is used on systems that do not have that system call.
The problem with select() on Linux is not due to anything on Linux. The
operating system is perfectly capable of correctly executing a binary that
was built with that include file bug fixed...even if the bug is not fixed
on the system running the resulting binary! Similarly, there is no reason
to believe that a different compiler would have that bug.
Since the problem is not in binary execution, but rather in a certain
compiler on a certain system generating incorrect binary code, the correct
fix is to fix the compiler. In this case, it is a one line change to an
include file, not a compiler binary.
-- 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
