>Casper.Dik at Sun.COM wrote: >> >Due to the 32-bit ABI's stdio file descriptor limit, an interposer is >> >being used to F_DUPFD non-stdio file descriptors to 256 and above. This >> >mitigates a problem with 3rd party modules and plugins that use >> >fopen(3C), et al. streams in processes such as Apache HTTP Server that >> >open a large number of file descriptors. Unfortunately, using the >> >interposer causes failures when a child process (e.g. CGI program) >> >subsequently invokes telnet(1). If telnet passed the correct nfds value >> >to select(3C), that failure would be eliminated. >> >> In build 39 of Nevada we provide a standard interposer, >> /usr/lib/extendedFILE.so, which has a similar, but different property. > >Umpf... for the same reason we were thinking about making the >stdio-replacement API in libast public since it it supports an almost >unlimited number of stdio channels...
Note that /usr/lib/extendedFILE.so does *not* use F_DUPFD; it calls enable_extended_FILE_stdio(-1, -1) which makes a gaurantee on behalf of the application that it does not reference FILE._file and in return the C Library allows for the use of file descriptors > 255. The kernel and the C library conspire such that any use of a FILE._file for FILE's opened with a file descriptor over 255 will cause the application to die with SIGABRT. Casper
