Re: story posted
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 equal, but to improve adaption first 2.0 needs to be an established entity and with 2.1 the will have a bad signal/noise ratio. Harrie -- Author of MOD-SNMP, enabling SNMP management of Apache HTTP server
Re: story posted
2.1 was started so that 2.0 can remain stable from here on out instead of changing the 2.0 API with every minor release, requiring everyone to re-port their modules with every minor 2.0 release so the fact that 2.1 exists is a very good sign for 2.0! Dave - Original Message - From: 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 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 equal, but to improve adaption first 2.0 needs to be an established entity and with 2.1 the will have a bad signal/noise ratio. Harrie -- Author of MOD-SNMP, enabling SNMP management of Apache HTTP server
Re: story posted
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 avoid the whole thing? It boils down to where our time is best spent. Yes, we can come up with all sorts of tricks to sorta-kinda-almost make this work. But why? What do we gain? At this point most of us feel that we really don't gain anything. -Rasmus On Sun, 9 Feb 2003, Glenn wrote: 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-thread-safe library would suffer a performance penalty, they would still work! If the core of PHP is thread safe, then this should not be a big deal. Also, as time goes on, third party library locks can be removed as thread-safe versions of the libraries become available. For a well-written and concise explanation, please refer to: http://www.unet.univie.ac.at/aix/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm Cheers, -Glenn On Fri, Feb 07, 2003 at 02:02:39AM +0100, Sascha Schumann wrote: 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 compiled in thread-safe mode. The first SAPI module for a threaded UNIX web server was completed in the same year (for AOLserver). It's safe to assert that we need to primarily worry about 3rd party libraries. Also blaming on use of TLS seems a little strange since use of TLS is supposed to improve re-entrancy isn't it ? Let me just quickly define what these concepts refer to. Thread-safe means that you can run code in multiple threads concurrently (e.g. multiple worker threads). Reentrant means that you can run code in a single thread context in a nested way (e.g. Apache sub-requests). Thread local storage aids only the former one. From my point of view we should not worry about reentrancy right now, at least not until we a have firm grasp on the 3rd party TS issues. - Sascha
Re: story posted
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 2.0 because Apache 2.0 must be fixed before such a thing is even possible? I see more comments implying b) than a). As such, it seems that anybody that wants to hack PHP to work better with 2.0 is wasting their time. The comments implying b) have to do with the problems with implementing PHP as a filter versus PHP as a handler. The discussion on that front has been positive and I'm hopeful that a solution can be reached. 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. I wrote: It's trivial to make a library thread safe by serializing access to the functions of the non-thread-safe library. and Rasmus' irked response was: Do you really think we don't know this? I do think you know this. I was making a point and I thank you for your help in doing so. Rasmus continued: It boils down to where our time is best spent. Yes, we can come up with all sorts of tricks to sorta-kinda-almost make this work. But why? What do we gain? At this point most of us feel that we really don't gain anything. I respectfully request that PHP developers own up to the fact that while there are issues with Apache2 and PHP as a filter/handler, that the main reason why mod_php is not production ready with Apache2 is because of the PHP developer non-interest in fixing the PHP core non-reentrancy (use of thread local storage) and because PHP uses many non-thread-safe third party libraries and does not think it worth the time to protect accesses to those non-thread-safe functions. If properly documented, you might find some people willing to tackle the problem rather than finger pointing at the Apache developers. Currently, PHP propaganda implies that the reason is the ASF's fault. Yes, PHP is the #1 module in Apache, but Apache installations generally serve content in addition to PHP. The new threading models make a huge difference in performance on some platforms for that additional content and it is egomaniacal to refuse to acknowledge that people use Apache for more than just PHP. Will a possibly slower Apache2 PHP hurt more than help in such environments? I don't know and make no claims. My aim here is to clarify the issues to answer Jeff's question. Personally, my servers run PHP as CGI. Works well. Thank you. Kudos for safe_mode and safe_mode_gid. -Glenn Please direct flames to gs-apache-dev at gluelogic.com. They will be read and responded to privately.
Re: story posted
* 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 it simpler to just go prefork and avoid the whole thing? just an idea: why not make such mutexes configurable anyway? It would probably not be such a big effort and lets the user decide. It would need some documentation (why and when it's neccessary with some hints about TS), of course. nd -- Gib' mal folgendes in die Kommandozeile ein (und einen Moment warten): net send localhost Buuuh! Na, erschreckt? -- Markus Becker in mpdsh
Re: story posted
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. Thank you. Kudos for safe_mode and safe_mode_gid. ?? safe_mode and safe_mode_gid are rather useless when running PHP as a CGI. All you are doing is burning syscalls aimlessly and slowing everything down. If you are running PHP as a CGI anyway, run it under suExec. 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 server. And when attacked repeatedly on this issue we tend to point out that thread safety issues in commonly used libraries pretty much nullify any threading gains of the new architecture since we'd have to mutex them, and also the fact that the filter api's complexity isn't making life easy for us, nor does the architecture mesh well with how PHP likes to do things. As a handler under prefork it may work very well. Who knows. Feel free to apply for a CVS account and write it, but please stop trying to browbeat us into doing something. I personally have a working web server that does what I need. Show me something irresistible about this new server and I will be compelled to work on it myself. -Rasmus
Re: story posted
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 server. And when attacked repeatedly on this issue we tend to point out that thread safety issues in commonly used libraries pretty much nullify any threading gains of the new architecture since we'd have to mutex them, and also the fact that the filter api's complexity isn't making life easy for us, nor does the architecture mesh well with how PHP likes to do things. As a handler under prefork it may work very well. Who knows. Feel free to apply for a CVS account and write it, but please stop trying to browbeat us into doing something. I personally have a working web server that does what I need. Show me something irresistible about this new server and I will be compelled to work on it myself. ok. you know have 2 implementations of the handler based php sapi for use with apache2, instead of using the Filter API. www.apache.org/~ianh www.apache.org/~jerenkrantz/apache2handler I don't know PHP's code review process or how to check the code in (I have a CVS account for PHP) my limited testing of the code appears that it works correctly. --Ian -Rasmus
Re: story posted
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-thread-safe library would suffer a performance penalty, they would still work! If the core of PHP is thread safe, then this should not be a big deal. Also, as time goes on, third party library locks can be removed as thread-safe versions of the libraries become available. For a well-written and concise explanation, please refer to: http://www.unet.univie.ac.at/aix/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm Cheers, -Glenn On Fri, Feb 07, 2003 at 02:02:39AM +0100, Sascha Schumann wrote: 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 compiled in thread-safe mode. The first SAPI module for a threaded UNIX web server was completed in the same year (for AOLserver). It's safe to assert that we need to primarily worry about 3rd party libraries. Also blaming on use of TLS seems a little strange since use of TLS is supposed to improve re-entrancy isn't it ? Let me just quickly define what these concepts refer to. Thread-safe means that you can run code in multiple threads concurrently (e.g. multiple worker threads). Reentrant means that you can run code in a single thread context in a nested way (e.g. Apache sub-requests). Thread local storage aids only the former one. From my point of view we should not worry about reentrancy right now, at least not until we a have firm grasp on the 3rd party TS issues. - Sascha
RE: story posted
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 compiled in thread-safe mode. The first SAPI module for a threaded UNIX web server was completed in the same year (for AOLserver). It's safe to assert that we need to primarily worry about 3rd party libraries. Also blaming on use of TLS seems a little strange since use of TLS is supposed to improve re-entrancy isn't it ? Let me just quickly define what these concepts refer to. Thread-safe means that you can run code in multiple threads concurrently (e.g. multiple worker threads). Reentrant means that you can run code in a single thread context in a nested way (e.g. Apache sub-requests). Thread local storage aids only the former one. From my point of view we should not worry about reentrancy right now, at least not until we a have firm grasp on the 3rd party TS issues. - Sascha
Re: story posted
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. On Solaris - Absolutely ! Dw.
Re: story posted
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 tell you this -- until it does I have to stick with Apache 1.3.x. Nobody is trying to push people to Apache 2.0 that rely on modules that aren't quite ready. To me, this subthread is all about clarifying exactly what technical issues with Apache 2.0 is preventing some module such as PHP from being production ready. I think we all know the non-technical reasons. developers out there saying the same thing. I'm also sure that the uptake to 2.0 is absolutely hindered because of this incompatibility. certainly I would imagine that this problem would create some sense of urgency to get these two to work together -- and definitely more so on the side of the Apache developers since PHP is the #1 module in use out there for Apache. I for one want to first cut through the quotables and find out what needs to be changed with Apache 2.0 so that PHP can be production ready with Apache 2.0. Apparently, that is nothing. With no signals to the contrary, and maybe some hints on what is problematic, then hopefully more people who want/need it to work will realize the light is green. Don't offer me a CVS account and suggest that I come and fix it myself. That's how all this development (Apache or PHP) works anyway... don't feel pained about being offered the tools to help yourself, since what apparently is your production environment is as productive for you only because somebody took up the exact same offer in the past. Such an offer is the way to make it clear that nobody is standing physically in the way of making it better, even if personal priorities may be different and people have to pick up the load themselves rather than waiting for it to be done by the core developers. I'm up to my eyeballs as it is. Until Apache 2.x works with PHP, I'm sticking with 1.3.x. Sorry. understandable, though I would phrase it differently :)
Re: story posted
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 features of Apache 2.0. Sure, I'd like to make the move and in fact tried to until I bumped my head on the wall finding out the hard way that it doesn't get along with PHP. There exist instructions that describe how to install Apache 2 and PHP: http://dan.drydog.com/apache2php.html Of course, you will need to check out known issues, for instance this bug: http://bugs.php.net/bug.php?id=21634 I have Apache 2 and PHP running with no big problems so far. And I'm sure there are tones of other PHP developers out there saying the same thing. I'm also sure that the uptake to 2.0 is absolutely hindered because of this incompatibility. I would imagine that this problem would create some sense of urgency to get these two to work together -- and definitely more so on the side of the Apache developers since PHP is the #1 module in use out there for Apache. Is it really #1 module?? *sigh* Don't offer me a CVS account and suggest that I come and fix it myself. I'm up to my eyeballs as it is. Until Apache 2.x works with PHP, I'm sticking with 1.3.x. Sorry. 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). - Dmitri.
Re: story posted
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). Most reported bugs are actually user error, and there are volunteers who are usually not actually hard core PHP developers who go through and clean up the bug reports and ask for more info when needed. They don't always get it right, but they reduce the load on the developers who tackle the tough problems. -Rasmus
Re: story posted
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 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 2.0 because Apache 2.0 must be fixed before such a thing is even possible? I see more comments implying b) than a). As such, it seems that anybody that wants to hack PHP to work better with 2.0 is wasting their time. I'm still catching up on email, so apologies if someone has already replied to this... There are two basic problems in getting PHP to work with Apache 2: 1) PHP wants to pull data (both POST bodies and php scripts); but Apache 2 output filters want to push data. Buffering the entire output stream is not feasible. 2) PHP depends on many third party libraries, many of which are neither reentrant nor threadsafe. -aaron
Re: story posted
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
Re: story posted
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 how it appears to the end-user at least. I don't buy that argument. Are you saying that if Apache 1.4 had been released with a couple extra modules but no threading or filters, then PHP would have stuck with 1.3 because it works well enough? No, I hope PHP would have updated to 1.4 to take advantage of the current development efforts. Those development efforts include not just a couple new modules (major ones like mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, etc), but lots and lots of other enhancements (IPv6, PCRE, improved negotiation, better documentation, better non-unix support, many bug fixes, etc). 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. There is no such thing anymore as a handler in Apache 2.0, am I correct? Aren't the handler-like hooks that try to behave the same was as they did in 1.3 just implemented over output filters? -aaron
Re: story posted
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 filter chain in brigades
Re: story posted
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 for a sharp mod_perl usage dropoff in 2002, from over 35% to around 20%? - Dmitri.
Re: story posted
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.
Re: story posted
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 to begin with. yea, it's more flexible but that flexability comes at a high cost. And if no one is interested in what that extra flexability gains you, then the only thing accomplished is the code is more complex and bug prone. You know the saying if the only tool you have is a hammer, then all problems look like nails? Well for a while, apache 2.0 filters were 'the hammer'. Hopefully that is changing now. I don't see how making it a handler will fix this problem. PHP will still want to read input bodies from the input filter chain. Also, I should point out that something as seemingly simple as an SSI file that includes multiple php scripts needs the filter stack. -aaron
Re: story posted
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 filter was a good idea to begin with. yea, it's more flexible but that flexability comes at a high cost. And if no one is interested in what that extra flexability gains you, then the only thing accomplished is the code is more complex and bug prone. You know the saying if the only tool you have is a hammer, then all problems look like nails? Well for a while, apache 2.0 filters were 'the hammer'. Hopefully that is changing now. I don't see how making it a handler will fix this problem. PHP will still want to read input bodies from the input filter chain. Also, I should point out that something as seemingly simple as an SSI file that includes multiple php scripts needs the filter stack. -aaron So is that a popular configuration in use with 1.3 today? If not, then I hold this up as a trophy illustrating my earlier assertion regarding overengineered 'solutions' to non existent problems. Bill
Re: story posted
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 that if Apache 1.4 had been released with a couple extra modules but no threading or filters, then PHP would have stuck with 1.3 because it works well enough? No, I hope PHP would have updated to 1.4 to take advantage of the current development efforts. Those development efforts include not just a couple new modules (major ones like mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, etc), but lots and lots of other enhancements (IPv6, PCRE, improved negotiation, better documentation, better non-unix support, many bug fixes, etc). 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. There is no such thing anymore as a handler in Apache 2.0, am I correct? Aren't the handler-like hooks that try to behave the same was as they did in 1.3 just implemented over output filters? -aaron 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 are there to read POST'ed data. I would think it's not too terribly difficult to port 1.3 mod_php to 2.0 using the exact same handler model. Of course you still won't be able to embed php scripts in SSI tags (w/o doing unnatural things) but who really cares? Bill
Re: story posted
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 trophy illustrating my earlier assertion regarding overengineered 'solutions' to non existent problems. It doesn't really matter if it's in use by 1.3 today. If it's in use in 1.3 today then what use would 2.0 be? I've seen numerous bug reports stating this simple case. That to me validates this as a use case. -aaron
Re: story posted
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 are there to read POST'ed data. I would think it's not too terribly difficult to port 1.3 mod_php to 2.0 using the exact same handler model. Of course you still won't be able to embed php scripts in SSI tags (w/o doing unnatural things) but who really cares? I just looked at mod_cgi, and lo and behold it uses input and output filters for reading POST bodies and generating output, even though it's implemented in the handler hook. If you see any other handlers/generators that consume input bodies and use the APIs you're talking about, please point them out. 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
Re: story posted
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 scripts (same as how CGI does). my major concern is a php-script creating subrequests which include other php-scripts. forcing php to be re-entrant. is php re-entrant? or does it use globals/thread specific storage. if it does than php can not be used in a subrequest. Bill
Re: story posted
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 model. And all your processes use /tmp/somename to buffer data. - Sascha
Re: story posted
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 I hold this up as a trophy illustrating my earlier assertion regarding overengineered 'solutions' to non existent problems. It doesn't really matter if it's in use by 1.3 today. If it's in use in 1.3 today then what use would 2.0 be? I've seen numerous bug reports stating this simple case. That to me validates this as a use case. -aaron It is painfully obvious that the requirement is not important enough to the PHP team (or the majority of PHP users) to cause them to hack their code to enable it to work effectively as an Apache 2 filter. I honestly don't blame them for the decision. If we care about our users, our development time should be spent on the things that have the most benefit to our users. Spending large amounts of time rewriting (and destabilizing) code used by 100% of the PHP user base for the sole purpose of providing a piddly capability that will only be used by an infintesmal fraction of PHP users is not a good investment. IMHO. On an aside... I bet if you let mod_php be a handler, you can still do some pretty interesting things with output filters like mod_include. PHP would own the file descriptor and could be told (via config) to insert the SSI filter. Subrequests would be generated for the PHP tags and they would be handled by the PHP handler. I don't see that this requirement dictates PHP being a filter. Bill
Re: story posted
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.) Using temporary files is the only way to deal with it once you reach a certain threshhold. I implemented this for PHP's thttpd SAPI a few weeks ago. It's really simple. - Sascha
Re: story posted
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 multiple php scripts (same as how CGI does). Just came to the same conclusion in another response. my major concern is a php-script creating subrequests which include other php-scripts. forcing php to be re-entrant. is php re-entrant? or does it use globals/thread specific storage. if it does than php can not be used in a subrequest. Good question and I don't know the answer. Bill
Re: story posted
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
Re: story posted
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 the actually usefullness of php in general in a apache2 model. unless we can make php not use TLS and use request-specific data. (or have php pass a index into TLS so that each function knows what request it is actually parsing.) the other workaround to this I guess is to parse the entire php file in one shot, and then not allow the filter chain to get it's hand on a uncompleted php request, which would force php to serialize across the thread. so .. making this into a handler would require 2 things. 1. only grabbing post data once, (and for multiple php requests in the same page the first one gets it, and the others have undefined behavior) 2a. forcing php to evaluate the entire php script before moving onto the next one. (ie.. don't pass any data down the filter chain until php is done with the lot) or 2b. modifiy php to not use TLS and passing it a handle to it's local data making it re-entrant safe. 2b is a better solution, but I think 2a could be doable faster. is this plausable?
Re: story posted
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 executions might not work at all, I forgot to mention that I use preforking model. And all your processes use /tmp/somename to buffer data. 'somename' is random, I hope? - Dmitri.
Re: story posted
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 far. Two concurrent php script executions might not work at all, I forgot to mention that I use preforking model. And all your processes use /tmp/somename to buffer data. 'somename' is random, I hope? Never mind. Someone has replaced my initial hack which iterated over the incoming brigades and wrote the data into a temporary file with something which works with pure files only. That is more limited (files only), but avoids the concurrency issue. - Sascha
Re: story posted
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. Personally I never thought implementing PHP as a filter was a good idea to begin with. yea, it's more flexible but that flexability comes at a high cost. And if no one is interested in what that extra flexability gains you, then the only thing accomplished is the code is more complex and bug prone. You know the saying if the only tool you have is a hammer, then all problems look like nails? Well for a while, apache 2.0 filters were 'the hammer'. Hopefully that is changing now. I don't see how making it a handler will fix this problem. PHP will still want to read input bodies from the input filter chain. Also, I should point out that something as seemingly simple as an SSI file that includes multiple php scripts needs the filter stack. -aaron So is that a popular configuration in use with 1.3 today? If not, then I hold this up as a trophy illustrating my earlier assertion regarding overengineered 'solutions' to non existent problems. Exactly. Yes - a 'real' PHP filter would be terrific. In the meantime that 'filter' is broken, because it only accepts one file bucket. The PHP Apache hackers should take a page from the jakarta connectors flavors. If you want rock solid, use mod_jk. Experimental new efforts? You've got mod_webapp and mod_jk2 (APR based - even for Apache 1.3). Why toss the 'stable' and 'proven' php4apache, when you can simply port it to 2.0 and provide PHP content today? Sure - when folks want svn backing their PHP scripts you need a filter. But that should have been the what we are doing next instead of treating Apache2 filters as the nail and trying to be something it's not. Now we have the worst of both worlds... php4apache2 can't filter non-fd based buckets - so it's essentially broken for alternate script stores. But it doesn't do the filtering very cleanly either. 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? Bill At 11:50 AM 2/6/2003, Aaron Bannert wrote: There is no such thing anymore as a handler in Apache 2.0, am I correct? Aren't the handler-like hooks that try to behave the same was as they did in 1.3 just implemented over output filters? Ummm... look at mod_info or mod_status. Sure you can deal with brigades instead of the ap_rwrite APIs, but that doesn't mean that handlers don't exist. For that matter, what about mod_cgi? php4apache2 is going through httpd's default handler and filtering that result brigade. Simple enough for it to be its very own handler. For example, all the XBitHack stuff really never belonged in a filter in the first place. That flag should really only work for handlers that want to respect it (and the core handler doesn't know how to e'x'ecute text to the browser.) Bill
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 start finding thread-safety bugs. How long have Win32 users been doing PHP within threaded servers? We have gotten a number of TS bug reports, and what does Windows have to do with it? Most Windows libraries are threadsafe to begin with. We are not talking about TS issues in PHP here, we are talking about them in libraries that we have no control over. Sometimes these are even binary-only libraries. This is something that will eventually work itself out as developers become more aware and threaded apps start becoming more common on UNIX systems. But that doesn't change the fact that it is a real problem for us today. I would love to have a list of the known TS issues in the various 3rd-party libraries out there, and I did try to push that a bit with this: http://httpd.apache.org/docs-2.0/developer/thread_safety.html a while ago now. I was hoping for some more input here. We should be able to get to the point where we can tell people that Apache2+PHP+List of safe extensions is production-quality as long as they don't stray into any of the extensions/3rd party libs on the unsafe/unknown list. Right now that list unfortunately includes just about everything you can hook into PHP. -Rasmus
RE: story posted
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. Since similar arguments can be made for Apache core too. The same issue has certainly not stopped Apache 2.0 itself from going forward with full thread support. Apache core minds its own threading business and lets all the modules to mind (or not mind) their own ...despite the fact that using such a modules renders Apache server on a users m/c susceptible to the threading related disasters. Also blaming on use of TLS seems a little strange since use of TLS is supposed to improve re-entrancy isn't it ? Also the /tmp/somefile implementation that sascha was referring to was changed many releases ago. Given the availablity of TSRM (Thread safe resource manager) on PHP seems like a attempt in the direction. So is the thread safety issue exist due to not using TSRM where needed within PHP or cuz TSRM needs more work and there is more to it than just TSRM ? --Roshan -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 2: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 start finding thread-safety bugs. How long have Win32 users been doing PHP within threaded servers? We have gotten a number of TS bug reports, and what does Windows have to do with it? Most Windows libraries are threadsafe to begin with. We are not talking about TS issues in PHP here, we are talking about them in libraries that we have no control over. Sometimes these are even binary-only libraries. This is something that will eventually work itself out as developers become more aware and threaded apps start becoming more common on UNIX systems. But that doesn't change the fact that it is a real problem for us today. I would love to have a list of the known TS issues in the various 3rd-party libraries out there, and I did try to push that a bit with this: http://httpd.apache.org/docs-2.0/developer/thread_safety.html a while ago now. I was hoping for some more input here. We should be able to get to the point where we can tell people that Apache2+PHP+List of safe extensions is production-quality as long as they don't stray into any of the extensions/3rd party libs on the unsafe/unknown list. Right now that list unfortunately includes just about everything you can hook into PHP. -Rasmus
RE: story posted
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 assures that no globals get trounced... if a support function updates a variable 'foo', and several threads are calling the update function, none of the threads should trust the resulting value of 'foo' at any given time. You have no control of the kernel scheduler, so you don't know when your thread will be interrupted. Reentrant code is another matter, and occurs at two levels. Let's take a simple PHP example, suppose PHP can include a second virtual page, to which it calls back into Apache to provide. Apache decides that page is a PHP page, so it creates another request to PHP and runs it within the current thread. PHP may have assumed that the thread-local variables were safe, but the inner request modifies some thread-local values and, after returning from the inner, virtual request, the outer request will discover it's thread-local variables have all been corrupted. The other reentrancy issue are system interrupts. Wherever some async event or signal occurs, those same 'trusted' thread-local variables can be corrupted if the signal handler or async event driver calls that supposedly 'thread safe' code. So actually, the TLS storage problem ends up as our number one obstacle to true async design. Coders presume that replacing all of their globals with TLS resolved all of the multithreaded issues (as your post suggests, it's a common misunderstanding.) So now when we get Apache 3.0 ready - we discover all of this code that was once thread-safe really isn't. 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 off the request on one thread, but as various states of the request occur, the results might be dispatched from another thread. In short, TLS storage is really an evil wrapper to eliminate the greater evil of globals. It doesn't solve the problem five years from now ;-) Bill
Re: story posted
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 off the request on one thread, but as various states of the request occur, the results might be dispatched from another thread. would not such modules need to consider their operation atomic? otherwise much more than just the TLS would need replication.
Re: story posted
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 compatibility for N years? PHP has been one of the main problems we've seen in acceptance: people are scared off 2.0 because the PHP documentation has a big warning saying don't use PHP with 2.0 on production servers. joe
Re: story posted
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 think OS distributions will play a large role in this. When the Solaris / Redhat / Suse / IBM / Whoever people start shipping v2.0 with their OS'es (which has already started happening in the case of redhat) adoption will be quite quick. In addition, apache v2.0 comes with SSL + LDAP built in, where v1.3 did not - this will probably give people more reason to use it. Built in only to a point. The standard distribution does not contain either of these. What's more, you have to rebuild the core (or APR at least) and link these in to have either of these. Sorry, but this hits a nerve -- with Apache 1.3 we had 2 major sets of potentially incompatible binaries - EAPI and non-EAPI. With Apache 2.0 we have 2 x 2 (=4), i.e. SSL and non-SSL enabled and LDAP and non-LDAP enabled and permutations thereof. Is there any way we can stop linking LDAP and SSL into the core to use them, e.g. have mod_ssl be the only thing linking to OpenSSL and mod_ldap and/or mod_auth_ldap be the only modules linking to LDAP, i.e. so we can have one big mess of interchangeable binaries -- at least for a given MPM worker... [I have to believe this will settle down to worker for UNIX and the Windows worker for Windows for the 90+% case for a while anyway.] -- Jess Holle
Re: story posted
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-time about why 2.0 is the cat's pajamas. Unlike a commercial vendor we aren't caught between the rock and a hard place that forces vendors to trade off forcing users to go thru upgrade hell to assure they can pull down some more revenue. We get to build what we hope is a better thing and if it is people will migrate to it. We should not ever complain that other large constituencies haven't 'gotten with the program.' We should always talk about how it's hard for these large constituencies to move, to reengineer. Boy we have sympathy for it. We work with them. We respect them. Unlike a commercial vendor, we do not have an end-of-life plan for 1.3. We do no intend to have one. As long as people want to work on it, more power to them! Nobody should every be embarrassed that they haven't switched to 2.0. Try it, you'll like it. 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). Overtime that assured that it aligned nicely with the needs of the people that run real websites. The 2.0 crowd is more inward looking, very expert in how to engineer the web server engine. When the 2.0 enterprise emerged a lot of 1.3 folks wandered off, the refactoring work wasn't what they were passionate about. As 2.0 is adopted by the operational crowd we will see more contributors with those passions returning. They will help to make adoption and upgrade easier. They will help to polish the beast into something that is fits their needs better and better. Some of the rough going around the heavy weight complementary products (the middleware, the platforms, the larger sites, etc) is tied to that, or at least analogous to that. - ben Upgrade - the most frightening word in modern computing. On Tuesday, February 4, 2003, at 09:31 PM, Greg Stein wrote: 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 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? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: story posted
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 nobody has made it a high priority to make PHP production ready but instead because there is something flawed about Apache 2.0. 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. -Rasmus
Re: story posted
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 better scalability (ability to support large numbers of concurrent clients) than the prefork MPM. And just forget being able to efficiently use SMP architectures with the threaded MPM. Agreed. For some/many, prefork is just fine. Also, depending on the OS, worker may or may not be a 'Wow maker'. As you said, under Linux it's not a big diff, under other OSs (like Solaris), the difference is appreciable. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: story posted
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 because nobody has made it a high priority to make PHP production ready but instead because there is something flawed about Apache 2.0. 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. -Rasmus 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 2.0 because Apache 2.0 must be fixed before such a thing is even possible? I see more comments implying b) than a). As such, it seems that anybody that wants to hack PHP to work better with 2.0 is wasting their time.
Re: story posted
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 appreciably better scalability (ability to support large numbers of concurrent clients) than the prefork MPM. And just forget being able to efficiently use SMP architectures with the threaded MPM. I should have said Forget being able to efficiently use SMP architectures -on Linux- with the current pthread implementation. I am ranting about Linux because that is the OS that runs most Apache installations. Agreed. For some/many, prefork is just fine. Also, depending on the OS, worker may or may not be a 'Wow maker'. As you said, under Linux it's not a big diff, under other OSs (like Solaris), the difference is appreciable. 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. Bill
Re: story posted
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). Overtime that assured that it aligned nicely with the needs of the people that run real websites. The 2.0 crowd is more inward looking, very expert in how to engineer the web server engine. When the 2.0 enterprise emerged a lot of 1.3 folks wandered off, the refactoring work wasn't what they were passionate about. As 2.0 is adopted by the operational crowd we will see more contributors with those passions returning. They will help to make adoption and upgrade easier. They will help to polish the beast into something that is fits their needs better and better. Ben makes an extremely good point above. Not to be a fuddy-duddy, but when developing the 0.x - 1.3 releases, it was a lot about Why do I, as a web adminstrator/user want and need and we'd add that in. Just about every developer was also someone who depended on Apache. When 2.0 started, and up until recently, the majority of the effort was getting to a point where you had a server that ran well enough that you could consider adding real-world functional needs. Personally, I think the time and effort spent on getting the engine foundation right and featureful made sense, since it provides a much better platform for the operational aspects. Some things that someone would want to do, operationally, was darn near impossible with 1.3, but quite doable with 2.0. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: story posted
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 architecture to support binary
compatibility for N years?
I think OS distributions will play a large role in this. When the Solaris / Redhat /
Suse / IBM / Whoever people start shipping v2.0 with their OS'es (which has already
started happening in the case of redhat) adoption will be quite quick.
In addition, apache v2.0 comes with SSL + LDAP built in, where v1.3 did not - this
will probably give people more reason to use it.
Built in only to a point. The standard distribution does not contain either of
these. What's more, you have to rebuild the core (or APR at least) and link these in
to have either of these.
Sorry, but this hits a nerve -- with Apache 1.3 we had 2 major sets of potentially
incompatible binaries - EAPI and non-EAPI. With Apache 2.0 we have 2 x 2 (=4), i.e.
SSL and non-SSL enabled and LDAP and non-LDAP enabled and permutations thereof.
fudbuster method=dispell
Sorry but that's a pretty gross misstatement.
EAPI is an extension to the core server. It necessarily breaks binary
compatibility between modules (in a sometimes insignificant way - that's
for you - the module author - to determine for your module.) And you forgot
the third flavor, ApacheSSL, which also breaks compatibility. There is really
no reconciling a server built for SSL or without SSL with Apache 1.3.
With Apache 2.0, all of the hooks are there, all of the time. The core server
always remains compatible with all compiled modules, regardless of how that
core server was built (with or without SSL, with or without LDAP), with one
significant caviat. But SSL and LDAP have nothing to do with it, I have many
builds of mod_ssl alternately using OpenSSL and RSA's toolkit, and two LDAP
builds I'm working with, using both Netscape SDK and the Win32 API. The
point is I can load, or not load, any of those modules (although not two different
builds of the very same module.)
No, SSL and LDAP questions are FUD, that's for the RPM'er to determine.
(One caveat follows at the end.)
The real issue is how APR is built underneath Apache, and to a lesser degree
(because I consider the following a bug) how Apache made choices based on
APR's configuration. In other words, if APR is built without threading support,
you can't load a module that requires threading (even if Apache is running
prefork and the module does it's own thread pool magic.) If APR is built with
threading support, you can use prefork, worker or any other module. There are
some other more subtle distinctions in how APR is configured v.s. how it can
be used.
Those bugs, modules making choices based on APR build flags is usually
bad design. It's trivial to query the MPM to find out if the server is really using
multiple threads v.s. a single worker thread in each process. Testing the
APR_HAS_THREADS macro is usually the wrong choice for module authors.
But with good design, the author can ask APR if it supports or is using any
of a number of features at runtime, and can ask Apache what the profile of
the currently running MPM is (see mod_status and mod_info to get the
general idea.) And even across modules, optional functions allow one module
to publish functions that other modules may use (similar to EAPI, but much
more flexible and robust.) The best example here is mod_log_config, which
allows any module to add %{}n translations for a given character code.
The well designed module inquires of the optional function or registered
function, and if it can survive without finding that function, it should go
merrily on it's way without those specific features enabled.
So the simple fact is that with the 2.2 release we need to consider what
we advise module authors to code to ensure portability (and follow our own
advise), and we will finally eliminate the last vestiges of the EAPI problem.
/fudbuster
Is there any way we can stop linking LDAP and SSL into the core to use them, e.g.
have mod_ssl be the only thing linking to OpenSSL and mod_ldap and/or mod_auth_ldap
be the only modules linking to LDAP, i.e. so we can have one big mess of
interchangeable binaries -- at least for a given MPM worker... [I have to believe
this will settle down to worker for UNIX and the Windows worker for Windows for the
90+% case for a while anyway.]
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' CFLAGS/LDFLAGS.
Let's expect to fix that before releasing 2.2. And maybe consider always
enabling APR thread support while we are at it.
Bill
Re: story posted
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 next huge problem is thread-awareness of Unix libraries. There are still lots of issues with libraries which won't correctly in a threaded environment. 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. - Sascha
Re: story posted
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 because nobody has made it a high priority to make PHP production ready but instead because there is something flawed about Apache 2.0. 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. -Rasmus I don't agree that the filter API is a blooody mess, however I am sympathetic to the emotion your expressing. Is 2.0 complex? yes. Does it have a coherent design? IMHO, yes. Is it 'overengineered'? probably so. My criticsm of the filter API is that the design tries to solve too many problems and the resulting implementation is so complex that it creates an unnecessarily high entry barrier for folks interested in doing 2.0 module development. Apache httpd is a protocol engine that should provide useful services to folks building applications on top of it. The value is in the applications that run on top of httpd, not httpd itself. IMHO, application module developers are required to make an unnecessarily large investment (in time and effort) in becoming 2.0 experts before they can get their applications running. PHP is horribly complex, but PHP is where the value comes from so there is more incentive for folks to become masters of PHP. The same is not true of httpd 2.0. IMHO, a large part of our continuing 2.0 development effort should be in simplifying our current implementation while keeping the most important services we provide to app developers. Bill
Re: story posted
--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' CFLAGS/LDFLAGS. The majority of Unix platforms don't allow inheriting LDFLAGS from DSOs. Therefore, the core must dynamically link against OpenSSL and OpenLDAP not the modules. The run-time linker gets its search paths from the executable not the DSOs. So, I don't think you can do that portably. Let's expect to fix that before releasing 2.2. And maybe consider always enabling APR thread support while we are at it. APR thread support is always enabled if the platform has it (not sure why you think it doesn't). We've disabled it by default on FreeBSD because we know the thread libraries still has subtle quirks (user is free to override us by passing --enable-threads). We're trying to find someone with 5.0 and see if it is fixed. I believe Tony Finch has hinted that 5.1 might have the real fixes we need for FreeBSD. -- justin
Re: story posted
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 - Sascha
Re: story posted
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 objects as input. 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 to begin with. yea, it's more flexible but that flexability comes at a high cost. And if no one is interested in what that extra flexability gains you, then the only thing accomplished is the code is more complex and bug prone. You know the saying if the only tool you have is a hammer, then all problems look like nails? Well for a while, apache 2.0 filters were 'the hammer'. Hopefully that is changing now. The next huge problem is thread-awareness of Unix libraries. There are still lots of issues with libraries which won't correctly in a threaded environment. With the new Linux pthread implementations, folks will begin to see that threaded servers will offer big boosts in scalability and we'll start seeing more effort put into making popular PHP libraries thread safe. That's my crystal ball. Bill
Re: story posted
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 [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: story posted
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.0 must be fixed before such a thing is even possible? I see more comments implying b) than a). As such, it seems that anybody that wants to hack PHP to work better with 2.0 is wasting their time. Having looked at it in depth personally, I'll say a strong (a). Aaron and I had a good roadmap for how to get it all to work, and the only modifications we needed to make were in Zend and PHP. The current PHP Apache2 filter assumes that it can get a file handle and other silliness. But we never had the time to actually fix it The Right Way, and the other PHP people seemed to just want to say b! b! it's Apache's fault so we got into this finger-pointing standoff and nobody ever fixed anything. --Cliff
Re: story posted
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 linked into a PHP (or mod_perl) setup is questionable at best has not made us rush out to support Apache 2. If there was some compelling end-user feature that people clamoured for, it would be a different story, but as it is, Apache2 is just a headache for us. People would have to run in prefork mode so neither the architecture nor the performance are compelling arguments to switch for the end user. From our perspective, the additional effort required to field all these bug reports about Apache2+PHP+Worker doing weird and wonderful things makes it quite a PITA and we thus push people toward 1.3. Thread-safety issues are hard to debug and causes a lot of indecipherable and mostly useless bug reports. RedHat is currently my least favourite company due to the added support email load they have caused me. And yes, I know, Just tell them to use prefork. But with Apache-1.3 there is no Worker mpm and most of the time when you ask a user which mpm they are using, the response is a big fat, duh, mpm?. b) is PHP not production ready with Apache 2.0 because Apache 2.0 must be fixed before such a thing is even possible? I see more comments implying b) than a). As such, it seems that anybody that wants to hack PHP to work better with 2.0 is wasting their time. I don't think b) outweighs a) here. The issues in a) is the demotivator and b) is just the final nail in the coffin. If we were motivated enough we would work through the API stuff and figure out how to better get PHP aligned to the current filter approach. It's not like the Apache 1.3 API is super clean either. We just know it pretty well and PHP was built up around it almost from the beginning. I guess the real issue here is not even the end users as much as the developers themselves. Apache 1.3 was historically written by webmasters for webmasters running realworld servers. When/if Apache2 reaches a point where we, as developers, switch to using it for ourselves, PHP support will arrive in full force. As it is, it is just one server on the long list of servers somewhat supported by PHP. -Rasmus
Re: story posted
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 appears to the end-user at least. I don't buy that argument. Are you saying that if Apache 1.4 had been released with a couple extra modules but no threading or filters, then PHP would have stuck with 1.3 because it works well enough? No, I hope PHP would have updated to 1.4 to take advantage of the current development efforts. Those development efforts include not just a couple new modules (major ones like mod_ssl, mod_dav, mod_deflate, mod_auth_ldap, etc), but lots and lots of other enhancements (IPv6, PCRE, improved negotiation, better documentation, better non-unix support, many bug fixes, etc). The reality is that people can do SSL, DAV, Gzip, auth_ldap and everything else with 1.3. Things are a bit more coherent in 2.0 and from a design perspective it all fits together in a nicer way, but an end user just installs the appropriate package for 1.3 and it just works. The fact that the guy who rolled the package had a nightmare job to make it seamless is of no real concern to the end user. Our bread and butter here are the Linux and FreeBSD web servers out there. They do not run ipv6, they don't care about Windows and they certainly don't read documentation. What are we offering them? 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. Go for it. You sound motivated. http://www.php.net/cvs-php.php is where you sign up for a CVS account. I will make sure you, or anyone else here interested in helping out gets a CVS account promptly. -Rasmus
Re: story posted
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 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 features of Apache 2.0. Sure, I'd like to make the move and in fact tried to until I bumped my head on the wall finding out the hard way that it doesn't get along with PHP. And I'm sure there are tones of other PHP developers out there saying the same thing. I'm also sure that the uptake to 2.0 is absolutely hindered because of this incompatibility. I would imagine that this problem would create some sense of urgency to get these two to work together -- and definitely more so on the side of the Apache developers since PHP is the #1 module in use out there for Apache. That's a lot of people who simply cannot make the switch. Don't offer me a CVS account and suggest that I come and fix it myself. I'm up to my eyeballs as it is. Until Apache 2.x works with PHP, I'm sticking with 1.3.x. Sorry. -- Brandon
Re: story posted
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 play a large role in this. When the Solaris / Redhat / Suse / IBM / Whoever people start shipping v2.0 with their OS'es (which has already started happening in the case of redhat) adoption will be quite quick. In addition, apache v2.0 comes with SSL + LDAP built in, where v1.3 did not - this will probably give people more reason to use it. Regards, Graham -- - [EMAIL PROTECTED] There's a moon over Bourbon Street tonight...
