Subject: | fopen file descriptor limit |
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6221296
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234782
http://mail.opensolaris.org/pipermail/kerberos-discuss/2008-September/000272.html
In 32-bit mode, Solaris has an 8-bit field for storing the file descriptor number in a FILE
structure. Some types of applications may well have more file descriptors open when they
call into the krb5 library, where we use fopen. (Also kadm5, kdb, and rpc libraries.) From
some messages in the thread indicated above, it sounds like Sun's integration of 1.6.3 will
use a Sun-specific extension to stdio (not listed in the fopen man page in the Solaris 10 rev
we're running around MIT) to work around this; our code as shipped would just fail.
The FILE structure on the Mac has a 16-bit field for a file descriptor and a fileno_unlocked()
macro that examines it, though fileno() is a function that could bury some additional
workaround behavior. Using more that 65536 file descriptors does seem a bit excessive.
(But then, more than 640K of RAM did once too.)
GNU libc uses an int, so that looks okay.
I don't have function AIX, Tru64, etc., to examine. It's possible that it's only a real-world
problem on Solaris.
Possible approaches:
1) Ignore it unless someone gives us a patch. :)
2) Replace fopen calls with basic POSIX I/O, at least on these systems, and manage the
buffering (if we need it) ourselves. A shim layer would let us map it to stdio on systems
where it's not a problem, which is probably most of the modern ones too new to have big
legacy compatibility issues to worry about like Solaris does. (Keep ticket 6062 in mind if
tackling this.)
3) Use Sun's extension on recent-enough Solaris, ignore the problem elsewhere until/unless
we know it's an issue. I don't know if this supports using fileno() like we do for the close-
on-exec support.
4) ...?
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234782
http://mail.opensolaris.org/pipermail/kerberos-discuss/2008-September/000272.html
In 32-bit mode, Solaris has an 8-bit field for storing the file descriptor number in a FILE
structure. Some types of applications may well have more file descriptors open when they
call into the krb5 library, where we use fopen. (Also kadm5, kdb, and rpc libraries.) From
some messages in the thread indicated above, it sounds like Sun's integration of 1.6.3 will
use a Sun-specific extension to stdio (not listed in the fopen man page in the Solaris 10 rev
we're running around MIT) to work around this; our code as shipped would just fail.
The FILE structure on the Mac has a 16-bit field for a file descriptor and a fileno_unlocked()
macro that examines it, though fileno() is a function that could bury some additional
workaround behavior. Using more that 65536 file descriptors does seem a bit excessive.
(But then, more than 640K of RAM did once too.)
GNU libc uses an int, so that looks okay.
I don't have function AIX, Tru64, etc., to examine. It's possible that it's only a real-world
problem on Solaris.
Possible approaches:
1) Ignore it unless someone gives us a patch. :)
2) Replace fopen calls with basic POSIX I/O, at least on these systems, and manage the
buffering (if we need it) ourselves. A shim layer would let us map it to stdio on systems
where it's not a problem, which is probably most of the modern ones too new to have big
legacy compatibility issues to worry about like Solaris does. (Keep ticket 6062 in mind if
tackling this.)
3) Use Sun's extension on recent-enough Solaris, ignore the problem elsewhere until/unless
we know it's an issue. I don't know if this supports using fileno() like we do for the close-
on-exec support.
4) ...?