Re: [osol-discuss] fd limit on 32bit solaris i386 box
It would be simple to add a (maybe hidden) flag to the FILE * data structures that tell stdio that the calling program is aware of the new interface because it has been compiled with the new include files. There's always an issue with old libraries and such and FILE *'s being passed around to such libraries. This needs to apply to _endopen() which does the real work for fopen() and friends. Of course, stdin/stdout/stderr need to be patched too.. Then old binaries would see the old behaviro and new binaries (not using fileno() as macro) would be able to use more than 256 FILE * streams. The outline of the proposed implementation is something like this: - the ability to mark a file descriptors 3 = fd = 255 bad in the kernel (attempts to dup2() to it will fail and the kernel will never return it. close(badfd) fails with EBADF Any other operations will either fail with EBADF or will cause the kernel to send a pre determined signal. - FILE's can either use an ordinary fd = 255 or they can use a shadow fd; in the later case a flag is set in the FILE structure and the fp-_file is set to badfd. - the default behaviour still limits to 256 fds. - applications can request the behaviour by doing a specific call. - libraries can request no bounds FDs without affecting the behaviour for other programs (this means that badfd is not created under those circumstances); that part of the interface will likely not be supported (i.e., not a documented interface, only for use in Sun's libraries which now duplicate part of stdio just to get around the restriction. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fd limit on 32bit solaris i386 box
alessioc [EMAIL PROTECTED] wrote: I heard about a 256 fd limit on solaris 32bit boxes due to some stdio limit... will anything change in opensolaris? is it possible to increase this limit? This limit is an accidental feature from ATT. ATT did not understand that introducing SVr4 was the right time to break binary compatibility as SVr3 did use COFF and SVr4 did use ELF. Now it is too late for a clean update (except what Sun did with introducing 64 bit support). Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fd limit on 32bit solaris i386 box
[EMAIL PROTECTED] wrote: I heard about a 256 fd limit on solaris 32bit boxes due to some stdio limit... will anything chang e in opensolaris? is it possible to increase this limit? There's not 256 fd limit; there's a limitation on using file descriptors over 255 in FILE *s. I.e., once all fds = 255 are taken you can no longer fopen()/popen()/freopen() anything and fdopen with an fd over 255 will also fail. This limitation applies only to 32 bit processes. We're working on a mechanism to fix this but this is not straightforward as we'll need to prevent file corruption in old binaries. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org For folks interested in the details, the issue here is old binaries that were compiled with a fileno macro that directly dereferenced the char that holds the file descriptor. This was changed in 1998 (Solaris 7) to always be a function call with the fix for: 4155198 fileno() macro is evil and must be removed Note that other breakage may occur to programs that define their own FILE structures, since these would then be too small. Yet another example of why exporting a data interface from a shared library is intrinsically a bad idea. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fd limit on 32bit solaris i386 box
For folks interested in the details, the issue here is old binaries that were compiled with a fileno macro that directly dereferenced the char that holds the file descriptor. This was changed in 1998 (Solaris 7) to always be a function call with the fix for: 4155198 fileno() macro is evil and must be removed Note that other breakage may occur to programs that define their own FILE structures, since these would then be too small. Yet another example of why exporting a data interface from a shared library is intrinsically a bad idea. And why making datastructures public for efficiency reasons is bad. The 64 bit FILE is opaque and a bit bigger than the 32 bit FILE; this comes at the cost of no macros, functions only, for any stdio operation. And that is fine, these days. The 32 bit FILE is too small; it already has a shadow structure associated with it (before S9, it had three but I rationalized it into just one and made accessing the shadow structure O(1) rather than O(N) where N is the ordinal of the FILE * is the allocation sequence. One consequence is that FILE pointers copied like this: FILE mystdio = *stdio; don't really work as well because the library won't be able to locate the mbstate, buffer end and lock. We're working on putting the fileno() in the shadow structure but in a way which makes it safe; this is somewhat tricky because we'd like to be able to survive things like: fp-_file = open(); fd = fp-_file; doseomthing(fd); And with surviving we mean anything but data corruption. Aborting the process is fine; touching the wrong file descriptor or not touching the filedescriptor when we should is not. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] fd limit on 32bit solaris i386 box
I heard about a 256 fd limit on solaris 32bit boxes due to some stdio limit... will anything change in opensolaris? is it possible to increase this limit? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fd limit on 32bit solaris i386 box
alessioc wrote: I heard about a 256 fd limit on solaris 32bit boxes due to some stdio limit... will anything change in opensolaris? is it possible to increase this limit? It is possible to increase the limit, but not without breaking the ABI which would cause older programs to possibly not work anymore. And there's a perfectly good workaround to the problem: don't use stdio. Instead of fopen, use open. Instead of seek, use lseek. Instead of fclose, use close, etc. Using those routines you'll have (depending on the OS and settings) the ability to use thousands of descriptors. For vanilla Solaris 10 you'll have 1024 by default with a hard limit of 65536. -- James Lick -- 黎建溥 -- [EMAIL PROTECTED] -- http://jameslick.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fd limit on 32bit solaris i386 box
alessioc wrote: I heard about a 256 fd limit on solaris 32bit boxes due to some stdio limit... stdio is limited to 256 fd's per process in 32-bit apps due to backwards compatibility. Apps can use other I/O functions on fd's past 256 or compile as 64-bit to get around this. will anything change in opensolaris? is it possible to increase this limit? The default won't change, but you could change the source code and rebuild libc yourself if you don't care about binary compatibility with existing binaries from Solaris or other OpenSolaris systems. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] fd limit on 32bit solaris i386 box
I heard about a 256 fd limit on solaris 32bit boxes due to some stdio limit... will anything chang e in opensolaris? is it possible to increase this limit? There's not 256 fd limit; there's a limitation on using file descriptors over 255 in FILE *s. I.e., once all fds = 255 are taken you can no longer fopen()/popen()/freopen() anything and fdopen with an fd over 255 will also fail. This limitation applies only to 32 bit processes. We're working on a mechanism to fix this but this is not straightforward as we'll need to prevent file corruption in old binaries. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
