>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.
It makes use of a new framework in 32 bit libc to support fds > 255
in FILE *s.
This support consists of storing the integer fd in a shadow structure
and marking the FILE *s fd as "bad". This is done by marking one fd
in the kernel as bad. When an application uses fp->_file in a system
call, the kernel will send a SIGABRT to the process in question.
When an application modifies fp->_file for fds > 255, the next attempt
by libc to use the file descriptor will cause a call to abort().
Applications which never reference fp->_file will never fail in any
manner and will be free to use fds > 255.
It does not influence the fds on which files are opened.
The age old "library can't read file with fopen if first 255 fds are
open" can now be addressed by using a "F" modifier in
fopen/freopen/fdopen/popen.
E.g.,:
gethostent() {
FILE *fp = fopen("/etc/hosts", "rF");
}
(This does not disable the belt-and-suspenders protection but marks the
individual FILE *s as "large fd enabled")
So perhaps your putback is already obviated by the new support for
file descriptors over 255 in stdio.
Casper
