Just a last heads up before the release here. Do we really want this patch
in? I think that it was put in a bug-fix release in a rather hasty manner,
with no real reason. We've already experienced one crash, there may be
others - it's a very central piece of code.
Weighing the pros and cons of this patch, it basically fixes a problem that
isn't new or even unique to PHP, and existed ever since the days of PHP/FI
- The symptoms of this problem arise fairly rarely, in situations where
there's a combination of a web server that opens a very large number of
files[], and an operating system with a libc that can't handle fd's over
255 (Solaris). I think that saying that PHP is unusable under Solaris is a
gross overstatement; I've been aware of this issue since 1996, and yet,
I've come across less than a handful of real world cases that experienced
this problem, versus hundreds of cases that worked flawlessly. By
including the patch, we are fixing a problem that affects a very small
percentage of the userbase on Solaris[], at the price of a fairly big risk
in breaking functionality for existing users on ALL operating systems.
To summarize, including it in 4.3.2 (or anything in the 4.3.x series)
doesn't sound like good math to me. v5/ZE2 already has a fix for this, and
considering the urgency level of this issue, the sensitivity of the code it
touches, and the amount of testing that 4.3.x will get before it gets
released versus 5.x - waiting for 5 makes much more sense. For people who
experience this specific issue, we can provide the patch for 4.3.x on php.net.
I don't mean to start a big thread here - I feel very uncomfortable
releasing such a sensitive patch with so little testing, and don't exactly
understand why the problem that it addresses is suddenly so urgent. If
there's consensus here that this patch is important for this 4.3.x release,
so be it - I want to at least voice my opinion before it gets finalized.
Zeev
[*] Namely, users of multithreaded servers that actually use PHP in
threaded mode, which are relatively few; And users of Apache, configured
with hundreds of log files, which are also relatively few. There might be
other examples, but the problem certainly does not affect a typical
Apache/PHP setup. Specifically, it is NOT correlated in any way to the
number of include/require files that you have in your application - as long
as there's one fd under 255 handy, PHP will operate without any problems.
Just a last heads up before the release here. Do we really want this patch
in? I think that it was put in a bug-fix release in a rather hasty manner,
with no real reason. We've already experienced one crash, there may be
others - it's a very central piece of code.
Yes, it is indeed very central and that is the reason why the
old code caused so much trouble for a long, long time. It
fixes a nasty limitation on an important platform. Certain
SAPI modules like NSAPI, AOLserver, Apache 2 and thttpd are
severely affected by this issue - they are basically useless
on Solaris.
The patch has been extensively tested -- I have so much faith
in it, that is already running at a customer's site on
several Solaris installations.
If you want more exposure for the patch, I suggest rolling
another RC and using our far reaching announce mailing list
for generating feedback regarding the RC's quality for once.
- Sascha
At 05:32 20/05/2003, Sascha Schumann wrote:
Just a last heads up before the release here. Do we really want this patch
in? I think that it was put in a bug-fix release in a rather hasty manner,
with no real reason. We've already experienced one crash, there may be
others - it's a very central piece of code.Yes, it is indeed very central and that is the reason why the old code caused so much trouble for a long, long time.
It definitely wasn't too much trouble, there was next to no complaints
about it.
It
fixes a nasty limitation on an important platform. Certain
SAPI modules like NSAPI, AOLserver, Apache 2 and thttpd are
severely affected by this issue - they are basically useless
on Solaris.
Most of these SAPIs have been basically useless on all operating systems
until recently. Most of them are still not considered stable for
production use because of other threading issues. Despite this long list
of SAPIs, Apache 1.x SAPI users far outnumber the users of these SAPIs.
I had no doubt that you'd defend the introduction of this patch, you
wouldn't have introduced it otherwise. I'm more interested in hearing what
other people think, as I think they weren't made aware of the scope of the
problem and the risks involved.
Zeev
Zeev,
you are a bit late -- I'm afraid it would be riskier to
remove the fd patch and all related changes at this point
than just carrying on. I understand that you fear "late
breakage", because you have been involved in such events a
couple of times in the past. It's just natural to learn
from such mistakes and try to prevent them in the future.
In order to address that, I propose making a release
candidate announcement to a wider audience. The GCC folks
regularly use their announce mailing list for pre-releases.
If we do the same, it would help us tremendously to put the
spot on our release candidates and receive more diverse
feedback.
Any opinions?
- Sascha
I don't mean to start a big thread here - I feel very uncomfortable
releasing such a sensitive patch with so little testing, and don't exactly
understand why the problem that it addresses is suddenly so urgent. If
there's consensus here that this patch is important for this 4.3.x release,
so be it - I want to at least voice my opinion before it gets finalized.
I have the same feelings, I was not really happy by putting it in in the
PHP_4_3 either. (Though I'm not sure if I voiced that opinion on a
list). I think it's up to our release guy (Jani) to decide what to do
with it.
Derick
--
"my other box is your windows PC"
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/