# Core Dudes: Critical #20274 needs your input - Thread: https://externals.io/message/255 - Original archive: https://news-web.php.net/php.internals/255 - Started by Wez Furlong on 2003-03-25T11:37:54+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #255 — Wez Furlong — 2003-03-25T11:37:54+00:00 URL: https://externals.io/message/255#255 Problem: Solaris libc cannot `fopen()`/fdopen() more than 255 files. Additionally, it cannot handle file descriptors larger than 255. Although streams now avoids FILE* as much as possible, ZE1 requires FILE* in its flex scanners. Symptom: PHP SAPI implementations based on threads or that recycle processes may fail to open php scripts. If thread/process has already opened a number of files (such as log files opened for the web server), or has served previous requests, PHP can fail to open even the primary script file. Possible Solutions: 1. Backport my ZE-stream patch from ZE2. This would eliminate the problem entirely, as the ZE will no longer depend on the libc stdio implementation. However, this would cause a binary compatibility issue: in particular, the zend file handle structure needs to be memset to 0 before use; encoders and caches would probably need to have their source code patched for this to work nicely. 2. Do nothing to the PHP_4_3 code but: a) Suggest that people using PHP under Solaris use an alternative SAPI, such as CGI/Fast-CGI. Performance will not be as good, but at least the scripts will work reliably. -> http://www.thetaphi.de/php-ressources/ b) Suggest that they build apache + mod_php against glibc for Solaris if they really need better performance. The drawback here is that any libraries that they intend to use with apache/php also need to be compiled against glibc (== lots of compiling for them). 3. Is there another alternative that does not require a large amount of hacking in 4.3.x ? IMO, 1.) is the nicest fix, but it is probably too big a change to make in the 4.3.x series (especially with its impact on binary compatibility), so I'm -1 on doing this. It is worth noting that the perl guys have this same problem, and that even with the changes I made to ZE2, any code in PHP that uses FILE* is still affected by this issue. This means that we should make an effort to replace VCWD_FOPEN macro calls with either VCWD_OPEN, php_stream_open_wrapper or php_stream_fopen where possible in PHP5. Opinions please; we need to have an official resolution before 4.3.2 is released. ("Solaris sucks, use instead") --Wez. PS: Thanks to Uwe for doing the legwork/research on the cause of this problem. --- ## #256 — Larry Rosenman — 2003-03-25T11:39:53+00:00 URL: https://externals.io/message/255#256 · In reply to: #255 --On Tuesday, March 25, 2003 11:37:54 +0000 Wez Furlong wrote: > Problem: > > Solaris libc cannot `fopen()`/fdopen() more than 255 files. Additionally, > it cannot handle file descriptors larger than 255. > Although streams now avoids FILE* as much as possible, ZE1 requires > FILE* in its flex scanners. > > Symptom: > > PHP SAPI implementations based on threads or that recycle processes > may fail to open php scripts. > If thread/process has already opened a number of files (such as log > files opened for the web server), or has served previous requests, PHP > can fail to open even the primary script file. > > Opinions please; we need to have an official resolution before 4.3.2 is > released. ("Solaris sucks, use > instead") > There is an AT&T SFIO package that is a drop in replacement stdio package that fixes this for solaris. FWIW. > --Wez. > > PS: Thanks to Uwe for doing the legwork/research on the cause of this > problem. > > > -- > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 --- ## #257 — Wez Furlong — 2003-03-25T11:57:04+00:00 URL: https://externals.io/message/255#257 · In reply to: #256 http://www.research.att.com/sw/tools/sfio/ ? This sounds like a reasonable fix; we would need to add a configure check for this. (Although CFLAGS=-I/path/to/sfio/includes ./configure should also work). Uwe, could you try this out? Thanks for the suggestion Larry :) --Wez. > There is an AT&T SFIO package that is a drop in replacement stdio package > that fixes > this for solaris. --- ## #258 — Larry Rosenman — 2003-03-25T11:58:52+00:00 URL: https://externals.io/message/255#258 · In reply to: #257 --On Tuesday, March 25, 2003 11:57:04 +0000 Wez Furlong wrote: > http://www.research.att.com/sw/tools/sfio/ ? yep. > > This sounds like a reasonable fix; we would need to add a configure > check for this. (Although CFLAGS=-I/path/to/sfio/includes ./configure > should also work). > > Uwe, could you try this out? > > Thanks for the suggestion Larry :) My pleasure. when I was at a Solaris ISP, I used it for my Apache, and it worked great. LER > > --Wez. > > > > […] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 --- ## #259 — James Devenish — 2003-03-25T12:02:47+00:00 URL: https://externals.io/message/255#259 · In reply to: #255 In message on Tue, Mar 25, 2003 at 11:37:54AM +0000, Wez Furlong wrote: > Opinions please; we need to have an official resolution before 4.3.2 is > released. ("Solaris sucks, use > instead") Opinions? Okay: "PHP is a pain to compile and use reliably, arrive at realisation that advocates of were right". (I'd include a simley but I don't know whether its presence or omission would offend more people.)