Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:255
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 25 Mar 2003 11:37:54 +0000 (GMT)
To: internals@lists.php.net
cc: thetaphi@php.net
Message-ID: <Pine.LNX.4.53.0303251105550.25455@zaneeb.brainnet.i>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Core Dudes: Critical #20274 needs your input
From: wez@thebrainroom.com (Wez Furlong)

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.