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
+1 from me, but we need to make an extra effort to stress test the
lexer (the ini file parser as well as the language parser) in our QA
process.
Also, for the sake of binary compatibility (not sure just how much of an
issue this is here), its "nicer" to add the zend_open function pointer
to the end of the utility functions structure, rather than in the
middle.
What do Zeev/Andi think of this?
--Wez.
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
+1 from me, but we need to make an extra effort to stress test the
lexer (the ini file parser as well as the language parser) in our QA
process.
In our what?
A patched PHP inside of thttpd does not show any anomalies
after 100K ab requests:
test.php:
<?php
require "bar";
include "foo";
include "notthere";
bar:
<?echo "hi";
foo:
<?phpinfo();
As I mentioned earlier, including from URLs appears to be
broken even without my patches (we could call that a security
feature).
Also, for the sake of binary compatibility (not sure just how much of an
issue this is here), its "nicer" to add the zend_open function pointer
to the end of the utility functions structure, rather than in the
middle.
Moved. It would only affect applications which statically
initialize the structure.
- Sascha
Here is an updated version. Patch 01/03 are unchanged.
- Fixed fread argument order so that even my glibc likes it
- Improved file_handle code in the ini scanner
- Moved open_function struct member to the end
- Sascha
Just a note (didn't have time to review the patch, but I trust you :-),
that I'm +1 on the idea.
-Sterling
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
--
--
"First they ignore you, then they laugh at you,
then they fight you, then you win."
- Gandhi
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
Hi Jay,
This patch solves a lot of problems within PHP itself, but it is still a
good thing (tm) to link against sfio under Solaris in any case (third
party libs, and some of the less popular/maintained extensions will
still be using stdio).
So, the patch on its own is good, the patch combined with sfio is even
better. (Why can't Solaris fix their damned libc??).
If you can test it under iPlanet (initially, without using sfio), the
feedback would be much appreciated.
--Wez.
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:
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