: "Harrie Hazewinkel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 11, 2003 2:30 AM
Subject: Re: story posted
> Hi,
>
> Following this thread, I was wondering what the majority thinks
> is a best way forward. Currently, not many modules are
Hi,
Following this thread, I was wondering what the majority thinks
is a best way forward. Currently, not many modules are ready
for Apache 2.0 regardless the reasons.
But it seems already that work is done for Apache 2.1 and
people have to port their module again.
OK, the module API is almost eq
On Mon, 10 Feb 2003 11:42:49 -0800, Rasmus Lerdorf wrote:
> As for the Apache2+PHP stuff, we are not deflecting blame. We are simply
> not acknowledging that it is somehow our duty to drop everything and
> support Apache2 just because someone decided it was a good idea to release
> a new web serv
> On to a). The PHP developers have screamed quite loudly about the
> failings of Apache2, when, in fact, the largest reason why mod_php will
> not work with Apache2 is because it is not a priority for PHP developers.
Nobody is screaming.
> Personally, my servers run PHP as CGI. Works well. Th
* Rasmus Lerdorf wrote:
> Do you really think we don't know this?
>
> The point is that at this point we would basically have to mutex every
> call to every 3rd-party library function since we simply don't know which
> ones are threadsafe and which ones aren't. And if we lock everything,
> isn't
Jeff Trawick asked a well-directed pair of questions:
> What I think is useful information to people who want PHP+Apache-2.0 is:
>
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
>
> or
>
> b) is PHP not production ready with Apache
Do you really think we don't know this?
The point is that at this point we would basically have to mutex every
call to every 3rd-party library function since we simply don't know which
ones are threadsafe and which ones aren't. And if we lock everything,
isn't it simpler to just go prefork and
At the risk of inflaming an already tense conversation (too late),
I have to say that third party thread-safety issues are not a very
good excuse.
It's trivial to make a library thread safe by serializing access to the
functions of the non-thread-safe library. Although scripts that employ
the non
> Rather than fix the TS issues in all the 3rd party libraries
> that can be used with PHP's and its extension its more
> pragmatic to sort out thread/filter issues in PHP core.
The PHP project has been working on thread-safety since 1999.
All core components and most extensions can be com
On Thursday 06 February 2003 20:23 pm, you wrote:
> At 06:00 PM 2/6/2003, NAIK,ROSHAN (HP-Cupertino,ex1) wrote:
>
> And finally, TLS storage is a huge obstacle to ever implementing any
> multithreaded, async server that might service some request from
> multiple threads. Such a design might start
At 06:00 PM 2/6/2003, NAIK,ROSHAN (HP-Cupertino,ex1) wrote:
>Also blaming on use of TLS seems a little strange since use of TLS is
>supposed to improve re-entrancy isn't it ?
That's something of a misunderstanding... so I'll take a second to offer
an example of the difference.
Thread-safe code
:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: story posted
>
>
> > Perhaps it's best for someone to simply port php4apache to
> 2.0 and start
> > moving a little momentum. The thread-safety arguement is a
> little bogus,
> > until folks have something to s
> Perhaps it's best for someone to simply port php4apache to 2.0 and start
> moving a little momentum. The thread-safety arguement is a little bogus,
> until folks have something to start finding thread-safety bugs. How long
> have Win32 users been doing PHP within threaded servers?
We have gott
At 12:15 PM 2/6/2003, Bill Stoddard wrote:
>Aaron Bannert wrote:
>>On Wednesday, February 5, 2003, at 08:39 AM, Bill Stoddard wrote:
>>
>>>Then reimplement PHP as a handler/generator. You get the benefits of being able to
>install downstream filters w/o the headaches of implementing a filter. Pe
On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
> On Thu, Feb 06, 2003 at 07:42:56PM +0100, Sascha Schumann wrote:
> > On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
> >
> > > On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > > > > I have Apache 2 and PHP running with no big problems so
On Thu, Feb 06, 2003 at 07:42:56PM +0100, Sascha Schumann wrote:
> On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
>
> > On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > > > I have Apache 2 and PHP running with no big problems so far.
> > >
> > > Two concurrent php script execut
On Thu, 06 Feb 2003 19:47:52 +0100, Sascha Schumann wrote:
>> is php re-entrant? or does it use globals/thread specific storage. if it
>> does than php can not be used in a subrequest.
>
> It's not reentrant-safe and it uses TLS.
>
> - Sascha
ok.. then we have a major problem, limiting
> is php re-entrant? or does it use globals/thread specific storage. if it
> does than php can not be used in a subrequest.
It's not reentrant-safe and it uses TLS.
- Sascha
Ian Holsman wrote:
On Thu, 06 Feb 2003 13:22:28 -0500, Bill Stoddard wrote:
Of course you still won't be able to embed php scripts in SSI tags (w/o
doing unnatural things) but who really cares?
how so?
if we just make a rule saying that sub-requests don't get post data then
we could handle m
> In any case, the mod_cgi solution gets us back to the same
> problem we've always had with PHP, which is that we can't
> buffer the entire input body w/o having a huge memory impact on
> multithreaded servers. (We would need to buffer it because
> of the way PHP expects to consume input data.)
Aaron Bannert wrote:
On Thursday, February 6, 2003, at 10:15 AM, Bill Stoddard wrote:
Also, I should point out that something as seemingly simple
as an SSI file that includes multiple php scripts needs the
filter stack.
So is that a popular configuration in use with 1.3 today? If not,
then
On Thu, 6 Feb 2003, Dmitri Tikhonov wrote:
> On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > > I have Apache 2 and PHP running with no big problems so far.
> >
> > Two concurrent php script executions might not work at all,
>
> I forgot to mention that I use preforking mod
On Thu, 06 Feb 2003 13:22:28 -0500, Bill Stoddard wrote:
>
> Of course you still won't be able to embed php scripts in SSI tags (w/o
> doing unnatural things) but who really cares?
how so?
if we just make a rule saying that sub-requests don't get post data then
we could handle multiple php scrip
On Thursday, February 6, 2003, at 10:22 AM, Bill Stoddard wrote:
ROTFL...
This explains my earlier observation re "if the only tool you have
(amendment: or think you have) is a hammer, every problem looks like a
nail" :-)
Seriously, handlers exist in 2.0 (see modules/generators) and the APIs
On Thursday, February 6, 2003, at 10:15 AM, Bill Stoddard wrote:
Also, I should point out that something as seemingly simple
as an SSI file that includes multiple php scripts needs the
filter stack.
So is that a popular configuration in use with 1.3 today? If not,
then I hold this up as a tro
Aaron Bannert wrote:
Now, we could solve both problems by using a handler and
the prefork MPM. But then, Apache 2.0+PHP is basically
Apache 1.3+PHP with a few extra modules thrown in. That's
how it appears to the end-user at least.
I don't buy that argument. Are you saying t
Aaron Bannert wrote:
On Wednesday, February 5, 2003, at 08:39 AM, Bill Stoddard wrote:
Then reimplement PHP as a handler/generator. You get the benefits of
being able to install downstream filters w/o the headaches of
implementing a filter. Personally I never thought implementing PHP as
a
On Wednesday, February 5, 2003, at 08:39 AM, Bill Stoddard wrote:
Then reimplement PHP as a handler/generator. You get the benefits of
being able to install downstream filters w/o the headaches of
implementing a filter. Personally I never thought implementing PHP as
a filter was a good idea
On Thu, Feb 06, 2003 at 06:51:06PM +0100, Sascha Schumann wrote:
> > I have Apache 2 and PHP running with no big problems so far.
>
> Two concurrent php script executions might not work at all,
I forgot to mention that I use preforking model.
- Dmitri.
On Thu, Feb 06, 2003 at 06:50:08PM +0100, Sascha Schumann wrote:
> > > Is it really #1 module?? *sigh*
> >
> > Yup, by far.
>
> You can find the current data here:
>
> http://www.securityspace.com/s_survey/data/man.200301/apachemods.html
Something is fishy there. How would one account
Aaron Bannert wrote:
There is no such thing anymore as a handler in Apache 2.0, am I correct?
no, see default_handler, modules/generators/mod*.c
Aren't the handler-like hooks that try to behave the same was as they did
in 1.3 just implemented over output filters?
sure, output goes down fi
On Wednesday, February 5, 2003, at 08:27 AM, Joshua Slive wrote:
On Wed, 5 Feb 2003, Sascha Schumann wrote:
Now, we could solve both problems by using a handler and
the prefork MPM. But then, Apache 2.0+PHP is basically
Apache 1.3+PHP with a few extra modules thrown in. That's
> I have Apache 2 and PHP running with no big problems so far.
Two concurrent php script executions might not work at all,
if you look at the code. Maybe I'll spent some time today on
it and use fopencookie to create a proper stdio stream..
- Sascha
> > Is it really #1 module?? *sigh*
>
> Yup, by far.
You can find the current data here:
http://www.securityspace.com/s_survey/data/man.200301/apachemods.html
And for the archives, follow this link:
http://www.securityspace.com/s_survey/data/index.html
> Most reported bugs are
On Wednesday, February 5, 2003, at 08:02 AM, Jeff Trawick wrote:
Rasmus Lerdorf wrote:
Well, I stand by that. The filter API is a bloody mess. Something
which
should be simple and elegant has turned into this amazingly complex
tangle
of code that is nearly impossible to figure out.
What I
> Is it really #1 module?? *sigh*
Yup, by far.
> From my experience and that of some of programmers I know, PHP people are
> very reluctant to admit that they have bugs or fix their bugs. Usually
> they find it better to argue that you're the idiot and their code works
> (even when it does not)
On Wed, Feb 05, 2003 at 07:58:36PM -0800, Brandon Bell wrote:
> As an end user, I don't give a f*ck why it doesn't work! But I can tell
> you this -- until it does I have to stick with Apache 1.3.x. My sites and
> applications depend on PHP _way_ more then they depend on the nice new
> feature
Brandon Bell wrote:
Okay guys, I have to weigh in here as a non-developer and add a
comment re
all of this back and forth discussion on whether PHP or Apache 2.0 is the
problem for why they don't work/play together properly.
As an end user, I don't give a f*ck why it doesn't work! But I can te
On Wed, 5 Feb 2003, Bill Stoddard wrote:
> More like -huge-. The threaded MPM makes a big (think nearly an order of
> magnitude) difference in scalability on AIX. I expect the same is true
> on Solaris. I also think we will see similar results on Linux with
> either of the new pthread libraries.
Okay guys, I have to weigh in here as a non-developer and add a comment re
all of this back and forth discussion on whether PHP or Apache 2.0 is the
problem for why they don't work/play together properly.
As an end user, I don't give a f*ck why it doesn't work! But I can tell
you this -- until
On Wed, 5 Feb 2003, Joshua Slive wrote:
> On Wed, 5 Feb 2003, Sascha Schumann wrote:
> > Now, we could solve both problems by using a handler and
> > the prefork MPM. But then, Apache 2.0+PHP is basically
> > Apache 1.3+PHP with a few extra modules thrown in. That's
> > how it app
> What I think is useful information to people who want PHP+Apache-2.0 is:
>
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
That is a big part of it. The fact that the thread-safety of many
third-party libraries that can be linke
On Wed, 5 Feb 2003, Jeff Trawick wrote:
> What I think is useful information to people who want PHP+Apache-2.0 is:
>
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
>
> b) is PHP not production ready with Apache 2.0 because Apache 2.
Bill Stoddard wrote:
> Jim Jagielski wrote:
> > under other OSs (like Solaris), the difference
> > is appreciable.
>
> More like -huge-.
I should have put a winky after "appreciable".
--
===
Jim Jagielski [|] [EMAI
Sascha Schumann wrote:
a) is PHP not production ready with Apache 2.0 because it was not high
enough priority for PHP to be tested?
The current Apache 2 support in PHP is based on filters only.
That however is not well-supported by the scripting engine
which prefers real file object
> So why not just do a handler-based PHP for 2.0, and work on other problems
> in the future. This is a silly family quarel that is making everyone look
> bad.
We are looking forward to your contributions. Please apply
for a CVS account here:
http://www.php.net/cvs-php.php
--On Wednesday, February 5, 2003 10:09 AM -0600 "William A. Rowe,
Jr." <[EMAIL PROTECTED]> wrote:
This is a bug in the way Apache autoconf's... OpenSSL and OpenLDAP
should never be linked to the core... they should have been
detected and added only to the modules/ssl and modules/ldap
makefiles' C
Rasmus Lerdorf wrote:
You can also see text in our bug database from a prominent PHP developer
saying that the filter API needs to be redone from scratch (my
paraphrase). For the enthusiastic PHP users, such comments carry a lot
of weight and imply that PHP isn't production ready with 2.0 not
On Wed, 5 Feb 2003, Sascha Schumann wrote:
> Now, we could solve both problems by using a handler and
> the prefork MPM. But then, Apache 2.0+PHP is basically
> Apache 1.3+PHP with a few extra modules thrown in. That's
> how it appears to the end-user at least.
I don't buy that
> a) is PHP not production ready with Apache 2.0 because it was not high
> enough priority for PHP to be tested?
The current Apache 2 support in PHP is based on filters only.
That however is not well-supported by the scripting engine
which prefers real file objects as input.
The n
At 09:17 AM 2/5/2003, Jess M. Holle wrote:
>Graham Leggett wrote:
>
>>Greg Stein wrote:
>>
>>>Some questions for thought: if we start banging out versions right and left,
>>>then will people actually upgrade? Are we doomed to live with 1.3 forever?
>>>Or do we have to stick with today's architectur
At 10:25 AM -0500 2/5/03, Ben Hyde wrote:
>
>There is a fun transition in progress. The 1.3 crowd had a lot of people who were
>very passionate about operational focus - i.e. apache embedded as a component in a
>large complex system of other junk (people, business, middleware, whatever).
>Over
Jim Jagielski wrote:
Bill Stoddard wrote:
Running a threaded mpm on Linux is just not interesting today. The
memory footprint of the server is reduced, but so is the performance
(requests per second). Even worse, with the current Linux pthread
implementation, the threaded MPM does not provide
Rasmus Lerdorf wrote:
>You can also see text in our bug database from a prominent PHP developer
>saying that the filter API needs to be redone from scratch (my
>paraphrase). For the enthusiastic PHP users, such comments carry a lot
>of weight and imply that PHP isn't production ready with 2.0 no
Bill Stoddard wrote:
>
> Running a threaded mpm on Linux is just not interesting today. The
> memory footprint of the server is reduced, but so is the performance
> (requests per second). Even worse, with the current Linux pthread
> implementation, the threaded MPM does not provide appreciably
> You can also see text in our bug database from a prominent PHP developer
> saying that the filter API needs to be redone from scratch (my
> paraphrase). For the enthusiastic PHP users, such comments carry a lot
> of weight and imply that PHP isn't production ready with 2.0 not because
> no
Jim Jagielski wrote:
At 6:31 PM -0800 2/4/03, Greg Stein wrote:
Some questions for thought: if we start banging out versions right and left,
then will people actually upgrade? Are we doomed to live with 1.3 forever?
Or do we have to stick with today's architecture to support binary
compatibility
Putting on my PR hat - we could do a better job of getting out 'talking
points' ducks in line. Like Greg says that kind of marketing outreach
is not us. All the points Greg touched on in that article should be in
our talking points and there are more!
There should be 3-5 points we make every-
Graham Leggett wrote:
Greg Stein wrote:
Some questions for thought: if we start banging out versions right
and left,
then will people actually upgrade? Are we doomed to live with 1.3
forever?
Or do we have to stick with today's architecture to support binary
compatibility for N years?
I thi
At 6:31 PM -0800 2/4/03, Greg Stein wrote:
>
>Some questions for thought: if we start banging out versions right and left,
>then will people actually upgrade? Are we doomed to live with 1.3 forever?
>Or do we have to stick with today's architecture to support binary
>compatibility for N years?
>
V
Jeff Trawick wrote:
You can also see text in our bug database from a prominent PHP developer
saying that the filter API needs to be redone from scratch (my
paraphrase). For the enthusiastic PHP users, such comments carry a lot
of weight and imply that PHP isn't production ready with 2.0 not bec
Joe Orton wrote:
On Tue, Feb 04, 2003 at 06:31:10PM -0800, Greg Stein wrote:
...
>Some questions for thought: if we start banging out versions right
and left,
>then will people actually upgrade? Are we doomed to live with 1.3
forever?
>Or do we have to stick with today's architecture to suppor
On Tue, Feb 04, 2003 at 06:31:10PM -0800, Greg Stein wrote:
...
> Some questions for thought: if we start banging out versions right and left,
> then will people actually upgrade? Are we doomed to live with 1.3 forever?
> Or do we have to stick with today's architecture to support binary
> compatib
Greg Stein wrote:
Some questions for thought: if we start banging out versions right and left,
then will people actually upgrade? Are we doomed to live with 1.3 forever?
Or do we have to stick with today's architecture to support binary
compatibility for N years?
I think OS distributions will p
A while back, I received an interview request for a story on Apache 2.0 and
its adoption. I think that it turned out quite well, and the author appeared
to give a fair treatment overall.
Check out the story at:
http://www.newsfactor.com/perl/story/20572.html
Some questions for thought: if w
65 matches
Mail list logo
