Re: [PATCH] Deprecate use of stdio
| From: | Jay Smith | Date: | Fri, 02 May 2003 15:38:11 +0000 |
| Subject: | Re: [PATCH] Deprecate use of stdio | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-1164@lists.php.net to get a copy of this message | ||
I've been playing with sfio on Solaris quite a bit recently and I've had our
site working on iPlanet with sfio for a couple of weeks. Seems to be doing
okay so far with something between 4.3.1 and 4.3.2. Getting sfio to link
was a bit of pain in the arse at first, but it came down to a couple of
simple LIBS arguments to get it going.
As you say, fixing the problem at the root would be preferable, but sfio
might be a decent intermediary step.
I can test the patches and such on Solaris 8 SPARC, and if you (or anybody
who needs it, within reason of course) would like access to a Solaris
shell, I can arrange it. (It's slightly limited by a 300 MB quota, but
that's pretty much it.)
J
Sascha Schumann wrote:
> The following patches are aimed at deprecating the use of
> stdio by the script lexer in PHP 4, because certain stdio
> libraries impose restrictive limits on the number of open
> handles*.
>
> The patches have been split functionally for the benefit of
> the reviewer.
>
> Patch 1 adds a stream interface which fills in a
> zend_file_handle. This is simply a modified copy of the
> open_as_file function.
>
> Patch 2 adds zend_open() which expects the implementation to
> fill in a zend_file_handle.
>
> Patch 3 makes PHP supply a zend_open implementation.
>
> Patch 4 modifies the lexer skeleton so that it can read using
> POSIX functions and stdio. It also makes
> open_file_for_scanning use zend_open.
>
> * Background: Even the most modern Solaris ships with a stdio
> library which cannot handle fds over 255. This severely
> limits any web server which may open more than 255 fds per
> process, because it won't be able to parse PHP scripts
> anymore.
>
> I've evaluated integrating sfio into the build process, but
> as it turns out, a full and complete integration would be a
> lot more complex than addressing the issue up-front.
>
> - Sascha