This is the mail archive of the glibc-bugs@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/162] New: select() says fd's at EOF are ready for reading


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]