Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Core Dudes: Critical #20274 needs your input »

Core Dudes: Critical #20274 needs your input

php.internals

Wez Furlong

23 years ago
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 <insert_name_of_not_so_broken_os_here> instead") --Wez. PS: Thanks to Uwe for doing the legwork/research on the cause of this problem.

Larry Rosenman

23 years ago
--On Tuesday, March 25, 2003 11:37:54 +0000 Wez Furlong <wez@thebrainroom.com> 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 <insert_name_of_not_so_broken_os_here> > 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. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- 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

Wez Furlong

23 years ago
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. On Tue, 25 Mar 2003, Larry Rosenman wrote:

Larry Rosenman

23 years ago
--On Tuesday, March 25, 2003 11:57:04 +0000 Wez Furlong <wez@thebrainroom.com> 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. > > On Tue, 25 Mar 2003, Larry Rosenman wrote: >> There is an AT&T SFIO package that is a drop in replacement stdio package >> that fixes >> this for solaris.
-- 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

Uwe Schindler

23 years ago
I tried to compile PHP with sfio but I failed because under solaris: * linking together with compatiblity libstdio-mt.a (-lstdio-mt) does not work because this works not for .so files. The linking to libc is not overwritten. If you compile a whole program with it, it works (the init code of libstdio-mt.a unlinks all references to libc). But SunONE/iPlanet servers are not available in sourcecode so you cannot recompile the main code. * To compile with sfio that it works you have to include everywhere the special version of "stdio.h" (not with <>...). So we need a #define and we should include it to php-config.h and remove all occurences of #include <stdio.h> from code... and link to "libsfio.a". But this did not work, if I include CFLAGS=... before the ./configure it appends the -I at the end of all includes and will not use the special version of stdio.h I think the problem is the <> around the standard includes, they have to be ""... * If I do it really hard by: CC="gcc -nostdinc -I/../sfio/include -I/usr/include" ./configure (to get the right search order) The compiler claims about some redefinitions and stops somewhere in pthread.h :( Larry: Do you know how I could do this? Uwe At 05:58 25.03.2003 -0600, you wrote:
>--On Tuesday, March 25, 2003 11:57:04 +0000 Wez Furlong ><wez@thebrainroom.com> 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. >> >>On Tue, 25 Mar 2003, Larry Rosenman wrote: >>>There is an AT&T SFIO package that is a drop in replacement stdio package >>>that fixes >>>this for solaris. > > > >-- >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 > >
----- Uwe Schindler Addr 1: Bamberger Str. 24a, D-96049 Bamberg Addr 2: Drausnickstr. 153, D-91052 Erlangen http://www.thetaphi.de - http:///www.schindlers-software.de eMails: uwe@thetaphi.de (private); info@schindlers-software.de (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen!

James Devenish

23 years ago
In message <Pine.LNX.4.53.0303251105550.25455@zaneeb.brainnet.i> 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 <insert_name_of_not_so_broken_os_here> > instead")
Opinions? Okay: "PHP is a pain to compile and use reliably, arrive at realisation that advocates of <insert_other_thing_here> were right". (I'd include a simley but I don't know whether its presence or omission would offend more people.)