Re: Solaris fopen issue

[Joseph Kowalski <Joseph Kowalski eng sun com>]

> From: Owen Taylor <otaylor redhat com>
...
> > I have run into problems of GTK using fopen on Solaris.
> > The Solaris implementation has a problem with any fopen() which opens
> > a file above the 256 file descriptor.
> > 
> > How can I get around the problem ?
> > I use gtk 2.4.9 on Solaris 5.10. I created a program that emulates my
> > situation. It's a simple "Hello World" GTK application that opens 300
> > file descriptors with open(2) before gtk_init called.
> > It crashes with mesages below:
> > The Solaris implementation has a problem with any fopen() which
> >    opens a file above the 256 file descriptor.
> 
> I'm slightly speechless here, though I'm sure there are valid historical
> compatibility reasons for why Sun can't fix that problem. 
> 
> I'd suggest, if you really need that many file descriptors *open*, maybe
> just start your GUI earlier ... the use of stdio in pango and fontconfig
> is limited to reading configuration files.
> 
> It *would* of course, be possible to rewrite Pango to not use stdio,
> and use, say, GIOChannel instead. Feel free to file a bug report in
> Bugzilla to that effect, but don't expect it to get high prioritization,
> unless Sun has a patch sitting around....

Ah yes, the legendary 256 file limit on stdio.

This topic came up 6-9 months ago.  I remember answering the "why?" question
in private.  Maybe I should answer it in public.  After all, I was there.
If you want to shoot somebody for this oversight, you can shoot me; I was
the project lead for the SunOS portion of Solaris 2.0 (Solaris 0 by the
new naming). The macro was missed as an issue.  Besides, things were a bit
different in 1989.

The System V ABI, and early Solaris releases have fileno as a macro.  This
means that the **byte** which contained the file number in the FILE structure
was hardwired into the application (macros - just say "no").

Sun (or at least the Solaris organization) pays more attention to binary
computability than just about anybody.  You probably wouldn't believe
the things we worry about for compatibility.  Certainly something in the
ABI and stdio got a lot of respect.  Most (all?) the other System V
vendors just made the *incompatable* change years ago and forced a recompile.

Well, the good news is that this respect has run out.  In SunOS 5.7/Solaris 7
the fileno() macro was removed from the headers; only a real function exists.
Just a month or so ago, a change was put into Solaris to remove this
restriction in the belief that anything compiled on Solaris 6 or earlier
is either dead or irrelevant. The change is quite complicated (to maintain
computability in the absence of the fileno() macro) but you'ld almost
never know it was there. I'd assume by now its in the OpenSolaris world.

Sun never commits to contents of future releases, but this is targeted for
the next Solaris release and patches for existing releases.  I don't know
which releases patches are targeted for and even if I did I couldn't tell
you.  Just watch for Solaris patches in the not too distant future.

This probably doesn't do any of you any good today.

The "best practice" work around is to force all your non-stdio files to
be greater than 256...

	my_silly_fd_counter = 256;
	...
	tfd = open( ... );
	fd = dup2(tfd, my_silly_fd_counter++);
	close(tfd);

These leaves the file descriptors less than 256 available for stdio use
in libraries.  Pretty weird, huh?  The good news is you can hide this away
in a little routine and isolate the weirdness.

A kludgier approach is just to do a few dummy opens early in the program
flow and close them just before calling the library known to want to do
stdio.  This goes beyond the API, so its not guaranteed to work, and is
even more gross than the "best practice" above (IMHO), but may result in
less lines of code changed.

- cheers,

- Joseph Kowalski

Any opinions expressed are my own and not those of Sun Microsystems Inc.
Yadda, yadda, yadda, ...