Re: 2 questions: getter/setter use and streams use

On the contrary, it's easy to underestimate the problem :) If you are using a stdio replacement, (such as sfio), then you are more-or-less safe from the problem. The problem is that the native libc will not allow file descriptors with a numerical value > 255, regardless of your per-process file descriptor limit. If you are running under a longer-lived SAPI, the server or previous requests may have already bumped your descriptor usage above this limit (each open socket and file descriptor adds to the total). This means that any fopen(), fdopen() or popen() calls can fail without good reason. So, my advice to Solaris users is to use sfio where possible, and to keep an eye out for the error message "too many open files"; when you see it, you can try tuning your MaxRequestsPerChild (or equivalent) configuration setting in your web server and lower it, if possible. --Wez. On Mon, 14 Apr 2003, Jay Smith wrote: > > The problems people are having with iPlanet/Solaris/php seem to be the > result of incorrectly condfigured systems. (As mine was before upping the > maximum number of opened files per process -- I'm clueless on Solaris, so > sue me.) We've had a copy of our site running on Solaris 8 SPARC/iPlanet > box now a week and haven't hit any of those weird file limits, so I'm > starting to think that the problems in Solaris' stock libc are being > overexaggerated. > > J > > > George Schlossnagle wrote: > > > > > On Saturday, April 12, 2003, at 09:06 AM, Wez Furlong wrote: > >> Also note that you should not use ANSI stdio within PHP if you want > >> your > >> extension to be portable; AT&T based libc (Solaris) has braindead > >> limits > >> on the number of files you can open, and that limit may have already > >> been reached or exceeded even before PHP and the Zend Engine have been > >> started to handle the request. > > > > Not to sound like Sascha, but this shouldnt be an issue if you > > correctly configure your system. > > > > George > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > >