This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/162] New: select() says fd's at EOF are ready for reading
- From: "stl at nuwen dot net" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 15 May 2004 07:37:24 -0000
- Subject: [Bug libc/162] New: select() says fd's at EOF are ready for reading
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
The glibc documentation at
http://www.gnu.org/software/libc/manual/html_mono/libc.html#Waiting%20for%20I%
2fO says "A file descriptor is considered ready for reading if it is not at
end of file". This is the correct, desired behavior. (Why would you want select
() to say a socket is ready for reading if you can't get any bytes out of it?)
However, the man page on my Red Hat Linux 9.0 system (as well as other glibc-
using systems) documents the actual, undesired behavior of select(): "in
particular, a file descriptor is also ready on end-of-file".
I don't know what version of glibc my RHL 9.0 system uses.
This is a real problem, because if you give ANY sockets to select() and ask it
to check when data can be read from them, it always returns instantly. This
causes select()-based servers to spin hard, eating up 100% of the CPU.
Can glibc's behavior be made to match its documentation?
--
Summary: select() says fd's at EOF are ready for reading
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: gotom at debian dot or dot jp
ReportedBy: stl at nuwen dot net
CC: glibc-bugs at sources dot redhat dot com
http://sources.redhat.com/bugzilla/show_bug.cgi?id=162
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.