Re: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 12:17:24PM -0700, Rasmus Lerdorf wrote: Yup, definitely. They aren't always open source or sometimes they are just architecturally not fixabled. Step 1 is to gather information. I have committed an initial short list to httpd-2.0/docs/manual/developer/thread_safety.html where I plan on keeping track of stuff as the PHP bug reports flow in or I dive into each library to check out the code. In the spirit of doing something productive, I went through and added some notes to thread_safety.html for libraries I've used before in threaded environments or I read up on the relevant documentation. (If you have knowledge that contradicts whatever I said, then feel free to add or replace the comments.) The remaining libraries are primarily used with PHP, so I can't profess to have interacted with them. Hopefully, this will jumpstart this effort in the right direction. GDBM is certainly thread-unsafe, so we might want to consider yanking it from apr-util. -- justin
RE: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 12:17:24PM -0700, Rasmus Lerdorf wrote: Yup, definitely. They aren't always open source or sometimes they are just architecturally not fixabled. Step 1 is to gather information. I have committed an initial short list to httpd-2.0/docs/manual/developer/thread_safety.html where I plan on keeping track of stuff as the PHP bug reports flow in or I dive into each library to check out the code. In the spirit of doing something productive, I went through and added some notes to thread_safety.html for libraries I've used before in threaded environments or I read up on the relevant documentation. (If you have knowledge that contradicts whatever I said, then feel free to add or replace the comments.) The remaining libraries are primarily used with PHP, so I can't profess to have interacted with them. Hopefully, this will jumpstart this effort in the right direction. GDBM is certainly thread-unsafe, so we might want to consider yanking it from apr-util. -- justin +1 Bill
Re: Thread-unsafe libraries in httpd-2.0
We had this discussion elsewhere, but just for the record.. Justin Erenkrantz wrote: And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. IMNSHO, that is *such* BS. If someone has a working Web server and upgrades following our recommendations, and things stop working, it's not PHP that will get blamed. PHP still works just fine; there always has been the potential for trouble with threaded libraries, but that wasn't an issue because the Web server didn't use threads. What changed? The Web server; it started supporting threads. So it behooves the Web server to document the potential for problems. Why should the burden be put on PHP, or any other module for that matter? *They* weren't the ones that enabled threading. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: Thread-unsafe libraries in httpd-2.0
At 10:41 AM 8/16/2002, Rodent of Unusual Size wrote: And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. IMNSHO, that is *such* BS. If someone has a working Web server and upgrades following our recommendations, and things stop working, it's not PHP that will get blamed. PHP still works just fine; there always has been the potential for trouble with threaded libraries, but that wasn't an issue because the Web server didn't use threads. What changed? The Web server; it started supporting threads. So it behooves the Web server to document the potential for problems. Why should the burden be put on PHP, or any other module for that matter? *They* weren't the ones that enabled threading. I don't see what the big deal is here. It doesn't have to be one or the other. It REALLY is up to PHP and mod_perl to let their users know that they aren't thread-safe. It would also be helpful for Apache to let its users know that there are potential problems due to non-thread-safe third-party modules. As someone else posted, put a notice in the Apache distribution area that Apache 2.0 now supports threaded models, and before upgrading to Apache 2.0 and using one of the threaded models, users should check with each third-party module that they use to see if they're thread-safe. Then PHP and mod_perl can put notices in their distribution areas that some of the libraries they use aren't thread-safe, and that until this is fixed, users should not use any of the threaded models in Apache 2.0, and recommend use of the non-threaded models. -- Greg Marr [EMAIL PROTECTED] We thought you were dead. I was, but I'm better now. - Sheridan, The Summoning
Re: Thread-unsafe libraries in httpd-2.0
At 09:41 AM 8/16/2002, Rodent of Unusual Size wrote: We had this discussion elsewhere, but just for the record.. Justin Erenkrantz wrote: And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. IMNSHO, that is *such* BS. If someone has a working Web server and upgrades following our recommendations, and things stop working, it's not PHP that will get blamed. PHP still works just fine; there always has been the potential for trouble with threaded libraries, but that wasn't an issue because the Web server didn't use threads. And what was said elsewhere by someone else [not me] is that we've warned folks for THREE YEARS that Apache 2.0 would be threaded. What changed? The Web server; it started supporting threads. So it behooves the Web server to document the potential for problems. Document them *where*? As was pointed out on another list, quit bitching about it and propose docs-patches that would make you happy.. Why should the burden be put on PHP, or any other module for that matter? *They* weren't the ones that enabled threading. And they only had three years to prepare. The problems are not with PHP or with mod_perl, both support threading, and are thread-safe themselves. So now, what libraries are broken? That is what Rasmus, Justin, Doug and others are going to the trouble to research. So stop accusing our researcher/volunteers of BS, and quit spreading FUD yourself. If your module isn't threadsafe, check the mpm for threading support and bail. If your module *might* be threadsafe, but might not because of 3p modules, check the mpm for threading support and throw a warning. And once we finish preparing a list of known-thread-safe libraries/versions (and how to detect which version of each is present) we can go as far as warning the user that a specific library is known to be thread-unsafe and emit very loud build and run time warnings. Step one is research. Quit pissing off the researchers with your pronouncements from on high :-) Bill
RE: Thread-unsafe libraries in httpd-2.0
I don't see what the big deal is here. It doesn't have to be one or the other. It REALLY is up to PHP and mod_perl to let their users know that they aren't thread-safe. It would also be helpful for Apache to let its users know that there are potential problems due to non-thread-safe third-party modules. As someone else posted, put a notice in the Apache distribution area that Apache 2.0 now supports threaded models, and before upgrading to Apache 2.0 and using one of the threaded models, users should check with each third-party module that they use to see if they're thread-safe. If someone is looking for something to do here are some suggestions: Publish a tutorial on how to review code to see if it is threadsafe and reentrant (showing example of safe and unsafe implementations, list the 10 most common pitfalls that make a library not threadsafe (use of strtok and static variables, setting, incrementing/decrementing and testing of variables, etc.)). Maintain a list of know threadsafe/reentrant and unsafe libraries. Maintain a list of Apache 2.0 modules with known problems and hopefully be as specific as possible. If we can point out the problems, folks will likely step up and fix them. A remarkable number of software developers are really ignorant about programming in a threaded environment and I know from first hand experience with newbie software developers that it is really difficult for some people to grok that even a one instruction timing window where two threads can interfere with each other cannot be allowed. Anything we, the httpd developers, can do to help educate folks (even if it is just pointing them to good doc on writing threaded applications) is in our best interest. Bill
Re: Thread-unsafe libraries in httpd-2.0
Rodent of Unusual Size wrote: What changed? The Web server; it started supporting threads. only if the user explicitly does ./configure --with-mpm=something threaded on Unix So it behooves the Web server to document the potential for problems. Why should the burden be put on PHP, or any other module for that matter? documenting what we know about non-threadsafe libraries is a very positive step for users who want to experiment with threaded Unix web servers. But nobody is forcing users to do such experiments. *They* weren't the ones that enabled threading. see above. Greg
RE: Thread-unsafe libraries in httpd-2.0
At 10:21 AM 8/16/2002, Bill Stoddard wrote: A remarkable number of software developers are really ignorant about programming in a threaded environment and I know from first hand experience with newbie software developers that it is really difficult for some people to grok that even a one instruction timing window where two threads can interfere with each other cannot be allowed. Anything we, the httpd developers, can do to help educate folks (even if it is just pointing them to good doc on writing threaded applications) is in our best interest. +1 on documenting thread safety issues, for their benefit and our own (when folks submit patches or modules for inclusion in httpd!) Bill
Re: Thread-unsafe libraries in httpd-2.0
William A. Rowe, Jr. wrote: At 10:21 AM 8/16/2002, Bill Stoddard wrote: A remarkable number of software developers are really ignorant about programming in a threaded environment and I know from first hand experience with newbie software developers that it is really difficult for some people to grok that even a one instruction timing window where two threads can interfere with each other cannot be allowed. Anything we, the httpd developers, can do to help educate folks (even if it is just pointing them to good doc on writing threaded applications) is in our best interest. +1 on documenting thread safety issues, for their benefit and our own (when folks submit patches or modules for inclusion in httpd!) I think that the doc/pages that Rasmus started is an excellent 1st step. -- === 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: Thread-unsafe libraries in httpd-2.0
Rodent of Unusual Size wrote: We had this discussion elsewhere, but just for the record.. Justin Erenkrantz wrote: And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. IMNSHO, that is *such* BS. If someone has a working Web server and upgrades following our recommendations, and things stop working, it's not PHP that will get blamed. PHP still works just fine; there always has been the potential for trouble with threaded libraries, but that wasn't an issue because the Web server didn't use threads. What changed? The Web server; it started supporting threads. So it behooves the Web server to document the potential for problems. Why should the burden be put on PHP, or any other module for that matter? *They* weren't the ones that enabled threading. I fear that you're skipping a fundamental point: the modules *did* change. Their maintainers had to actively port the module code in order to release Apache 2.0 compatible versions of the modules. When they ported to 2.0, the requirements for module developers were the that they'd face if porting to any other threaded server: * If you're running in a multithreaded server, make your module code thread-safe. * If your module itself can load plug-ins at runtime, document the thread-safety requirements for the plug-in developers. That's no different from one would have to do when porting an Apache 1.3 module to, for example, the iPlanet httpd. IMHO, we should document the preceding guideline for module developers (that effort is already in progress) but a different message for end users: * If you're running 2.0 with a threaded MPM, and you add in 3rd party modules, make sure the providers of those modules guarantee that they'll work in a multithreaded application. * If any of those modules load other plug-ins at runtime via their own extension mechanisms (e.g., a page generation engine that can load plug-ins to connect to various databases), then you need to confirm that those plug-ins are thread-safe as well. Brian
Re: Thread-unsafe libraries in httpd-2.0
On Fri, Aug 16, 2002 at 11:41:53AM -0400, Jim Jagielski wrote: William A. Rowe, Jr. wrote: At 10:21 AM 8/16/2002, Bill Stoddard wrote: A remarkable number of software developers are really ignorant about programming in a threaded environment and I know from first hand experience with newbie software developers that it is really difficult for some people to grok that even a one instruction timing window where two threads can interfere with each other cannot be allowed. Anything we, the httpd developers, can do to help educate folks (even if it is just pointing them to good doc on writing threaded applications) is in our best interest. +1 on documenting thread safety issues, for their benefit and our own (when folks submit patches or modules for inclusion in httpd!) I think that the doc/pages that Rasmus started is an excellent 1st step. Could anyone recommend some reading on threading issues for people without much/any knowledge about threading? (Books/articles/etc) -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/ !(C)http://copywrong.dk/ http://apachegallery.dk/ Putting the HEST in .COM http://www.hestdesign.com/
Re: Thread-unsafe libraries in httpd-2.0
On Thu, 15 Aug 2002, William A. Rowe, Jr. wrote: There's no reason to bloat all of Apache and it's well behaved modules with extra code, when only a handful of modules care to report that they can't be compiled for a threaded architecture. The strict engineer in me agrees. The pragmatic engineer in me realizes that threading issues are hard, and that you're going to get more false positives (modules allowed to run who shouldn't be) if you make threading opt-out rather than opt-in. It's not like this code (or flag) has to be handled on every request. [Just in case that wasn't clear - modules should indicate that they are thread-safe, else the threaded MPMs should abort. Perhaps it would be sufficient to simply report an error or alert in the logs, so that when things go wrong, it occurs to the admin to consider thread-safety issues alongside other issues.] When it comes down to it, we're only talking about a couple extra lines for all of the standard modules to indicate that they are thread-safe. While that road does lead to creature feep, non-thread-safe code running in a threaded program can be very touchy, likely to work in a large number of cases, while crashing with weird, hard-to-debug symptoms. Later, scott
Thread-unsafe libraries in httpd-2.0
[ Moving to dev@httpd where this belongs ] On Thu, Aug 15, 2002 at 07:10:02AM -0700, Rasmus Lerdorf wrote: Correct. From the feedback I am getting, users do not adequately understand the implications of choosing a threaded MPM. We need to do a better job educating them to the fact that we simple cannot guarantee which libraries are threadsafe and which are not. Precisely which libraries are the core of httpd-2.0 using in a thread-unsafe manner? At least in the core distribution, we should have knowledge of which libraries are thread-unsafe and prevent this. To my knowledge, I haven't seen a single problem related to this. If you have actual cases where httpd-2.0 is doing something unsafe, please let us know! I think perhaps your concern is simply to PHP which may bring in thread-unsafe libraries not httpd-2.0. -- justin
Re: Thread-unsafe libraries in httpd-2.0
On Thu, 15 Aug 2002, Justin Erenkrantz wrote: [ Moving to dev@httpd where this belongs ] On Thu, Aug 15, 2002 at 07:10:02AM -0700, Rasmus Lerdorf wrote: Correct. From the feedback I am getting, users do not adequately understand the implications of choosing a threaded MPM. We need to do a better job educating them to the fact that we simple cannot guarantee which libraries are threadsafe and which are not. Precisely which libraries are the core of httpd-2.0 using in a thread-unsafe manner? At least in the core distribution, we should have knowledge of which libraries are thread-unsafe and prevent this. To my knowledge, I haven't seen a single problem related to this. If you have actual cases where httpd-2.0 is doing something unsafe, please let us know! I think perhaps your concern is simply to PHP which may bring in thread-unsafe libraries not httpd-2.0. -- justin As I have stated a dozen times now. Yes, I am talking about PHP and any other add-on module people may use. I think the attitude of most people here sucks. Apache doesn't have a problem, why should we do anything? The reality is that a big chunk of our Apache community uses Apache to serve up complex dynamic content using PHP, mod_perl, other 3rd-party modules and homegrown modules as well. PHP and mod_perl alone are on well over 50% of all Apache servers. People don't look to Apache for simply serving up static content. A lot of sites replaced Apache long ago with thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. -Rasmus
Re: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 09:40:06AM -0700, Rasmus Lerdorf wrote: thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. Making broad statements that will confuse our users like threaded MPMs may not be suitable for serving up dynamic content is a ridiculously overbroad and inaccurate statement. A better statement may be: Some PHP or Perl modules may not interact well with a threaded MPM in httpd-2.0. Caution is urged when using a threaded MPM. To me, that totally belongs in the PHP or Perl documentation. That is a limitation of PHP and mod_perl not of httpd-2.0. That statement doesn't hold for a mod_jk2 (or whatever the latest httpd-2.0 Tomcat module is). It totally depends on how the 3rd party module is architected not on the architecture of the web server itself. -- justin
Re: Thread-unsafe libraries in httpd-2.0
EXACTLY. Thanks, Justin. We are not trying to shirk our responsibilities or be lazy about this. But you can't say my module is so popular that you must account for problems that I introduce into your environment. I'm fine with adding something to our document that says something along the lines of, if you choose a threaded MPM such as FOO, BAR, or BAZ, then you need to ensure that the third-party modules you choose to use with the web server are thread-safe. Please contact your third-party modules' vendors for more information on their thread-safety. -g On Thu, Aug 15, 2002 at 10:09:27AM -0700, Justin Erenkrantz wrote: On Thu, Aug 15, 2002 at 09:40:06AM -0700, Rasmus Lerdorf wrote: thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. Making broad statements that will confuse our users like threaded MPMs may not be suitable for serving up dynamic content is a ridiculously overbroad and inaccurate statement. A better statement may be: Some PHP or Perl modules may not interact well with a threaded MPM in httpd-2.0. Caution is urged when using a threaded MPM. To me, that totally belongs in the PHP or Perl documentation. That is a limitation of PHP and mod_perl not of httpd-2.0. That statement doesn't hold for a mod_jk2 (or whatever the latest httpd-2.0 Tomcat module is). It totally depends on how the 3rd party module is architected not on the architecture of the web server itself. -- justin -- Greg Stein, http://www.lyra.org/
Re: Thread-unsafe libraries in httpd-2.0
That's just crap. I can say the same thing. PHP is threadsafe, it's not my responsibility that libxyz is not. Any Apache 2.0 module running under a threaded mpm linked against libxyz that contains non-threadsafe code is going to have exactly the same problem unless the module sticks in mutexes. Right now in the PHP world we simply tell people that they should not upgrade to Apache 2.0. If everyone ends up doing that, then I am sorry to say, but Apache 2.0 is dead and the current Netcraft statement is going to be a recurring thing. As a platform there are some cool possibilities with Apache 2.0 and I'd like to see it do well, but as a module author, being told to piss off and deal with the problem myself is not any way to encourage 3rd-party module support for Apache 2.0. In the end the users out there don't really give a crap about which web server they use. They just want something that works. Apache was always the web server that just worked. I strongly feel it is our job to help make sure that Apache remain the web server that just works. Like it or not, but the web server is the foundation for all the projects under the ASF umbrella and if we fuck up Apache, every sub-project will be hurt in the process. -Rasmus On Thu, 15 Aug 2002, Greg Stein wrote: EXACTLY. Thanks, Justin. We are not trying to shirk our responsibilities or be lazy about this. But you can't say my module is so popular that you must account for problems that I introduce into your environment. I'm fine with adding something to our document that says something along the lines of, if you choose a threaded MPM such as FOO, BAR, or BAZ, then you need to ensure that the third-party modules you choose to use with the web server are thread-safe. Please contact your third-party modules' vendors for more information on their thread-safety. -g On Thu, Aug 15, 2002 at 10:09:27AM -0700, Justin Erenkrantz wrote: On Thu, Aug 15, 2002 at 09:40:06AM -0700, Rasmus Lerdorf wrote: thttpd/Zeus/boa/Tux/khttpd for that. All I am after is a simple very visible addition to the Apache 2 distribution which explains that the threaded mpms may not be suitable for serving up dynamic content due to the unknown thread safety of the libraries these dynamic solutions rely on. And, my point back to you is that should be part of the documentation of the module NOT of httpd-2.0. Making broad statements that will confuse our users like threaded MPMs may not be suitable for serving up dynamic content is a ridiculously overbroad and inaccurate statement. A better statement may be: Some PHP or Perl modules may not interact well with a threaded MPM in httpd-2.0. Caution is urged when using a threaded MPM. To me, that totally belongs in the PHP or Perl documentation. That is a limitation of PHP and mod_perl not of httpd-2.0. That statement doesn't hold for a mod_jk2 (or whatever the latest httpd-2.0 Tomcat module is). It totally depends on how the 3rd party module is architected not on the architecture of the web server itself. -- justin -- Greg Stein, http://www.lyra.org/
Re: Thread-unsafe libraries in httpd-2.0
Rasmus Lerdorf wrote: That's just crap. I can say the same thing. PHP is threadsafe, it's not my responsibility that libxyz is not. Any Apache 2.0 module running under a threaded mpm linked against libxyz that contains non-threadsafe code is going to have exactly the same problem unless the module sticks in mutexes. how are we .. the apache group know what libraries you link to ? the only thing I can suggest technically is that we add a field in the module definition which says if the module is thread_safe. it would be up to the module developer to determine this, either based on the libraries he has linked in, or what color the trees are. if the module developer isn't certain about the thread safety of linked libraries he should set it to off. php could be really smart about this, and do this for it's own extensions.. and use the result of querying it's own extension for their thread safety. as the php extension developers certify their extensions php will be either thread safe or not. we as the apache group could then query the module when we load it (like we do to the magic number) and refuse to load a non-thread safe module into a threaded mpm. does this sound ok to you? snip
Re: Thread-unsafe libraries in httpd-2.0
That's not a bad idea, methinks. It would at least give us a reliable way to print an error message letting the user know why module foo can't be loaded: please try prefork if you need to use this module. Better than weird errors later in runtime. But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do the same. -wsv On Thursday, August 15, 2002, at 01:43 PM, Ian Holsman wrote: the only thing I can suggest technically is that we add a field in the module definition which says if the module is thread_safe.
Re: Thread-unsafe libraries in httpd-2.0
But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do the same. This is how I understood Ian's suggestion. That PHP asks its extensions whether they're thread-safe or not. And PHP itself tells Apache whether it - as a whole, i.e. including its extensions - is thread safe. j. -- A conference is a gathering of important people who singly can do nothing, but together can decide that nothing can be done. -- Fred Allen - http://jgcl.at/ko/ - new photos from summer camp 2002 in Moosen/Tirol
Re: Thread-unsafe libraries in httpd-2.0
Wilfredo Sanchez wrote: That's not a bad idea, methinks. It would at least give us a reliable way to print an error message letting the user know why module foo can't be loaded: please try prefork if you need to use this module. Better than weird errors later in runtime. But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do the same. exactly. php would ask it's extensions that are loaded/built in if they are threadsafe, and if any weren't then it would respond no until php has this functionality it could just return a blanket no this would work as long as php doesn't dynamically load extensions at request time. if it does then it could refuse to load a non-threaded dynamic extension into a already running threaded php. -wsv On Thursday, August 15, 2002, at 01:43 PM, Ian Holsman wrote: the only thing I can suggest technically is that we add a field in the module definition which says if the module is thread_safe.
Re: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 07:57:02PM +0200, johannes m. richter wrote:
But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do
the same.
This is how I understood Ian's suggestion. That PHP asks its extensions
whether they're thread-safe or not. And PHP itself tells Apache whether it
- as a whole, i.e. including its extensions - is thread safe.
FWIW, this infrastructure is already present within httpd-2.0.
ap_mpm_query(AP_MPMQ_IS_THREADED, *foo);
if (foo != AP_MPMQ_NOT_SUPPORTED) {
...we have threads...
}
HTH. -- justin
Re: Thread-unsafe libraries in httpd-2.0
Justin Erenkrantz wrote:
On Thu, Aug 15, 2002 at 07:57:02PM +0200, johannes m. richter wrote:
But does PHP ask HTTPD to load PHP modules? If not, PHP would need to do
the same.
This is how I understood Ian's suggestion. That PHP asks its extensions
whether they're thread-safe or not. And PHP itself tells Apache whether it
- as a whole, i.e. including its extensions - is thread safe.
FWIW, this infrastructure is already present within httpd-2.0.
ap_mpm_query(AP_MPMQ_IS_THREADED, *foo);
if (foo != AP_MPMQ_NOT_SUPPORTED) {
...we have threads...
}
it's not as obvious, the proposal above forces the developer to say
i verify my module will work with threaded
HTH. -- justin
Re: Thread-unsafe libraries in httpd-2.0
FWIW, I'm +1 on what Rasmus says - at least for widely used libraries. Obviously anything internal to PHP is PHP's problem. But anything everyone uses is our problem. However, I would advocate fixing the libraries rather than wrapping them where possible. Yup, definitely. They aren't always open source or sometimes they are just architecturally not fixabled. Step 1 is to gather information. I have committed an initial short list to httpd-2.0/docs/manual/developer/thread_safety.html where I plan on keeping track of stuff as the PHP bug reports flow in or I dive into each library to check out the code. -Rasmus
Re: Thread-unsafe libraries in httpd-2.0
On Thu, Aug 15, 2002 at 11:51:52AM -0700, Ian Holsman wrote: it's not as obvious, the proposal above forces the developer to say i verify my module will work with threaded No, I'd much prefer that modules code their own checks for it. A simple check in the pre_config hook phase should be sufficient. The PHP case would have to be done dynamically - it can't be done at compile-time, so a flag in the module structure at compile-time would not work. It would almost have to do something like I outlined before with a revamp of its extensions framework to indicate if a PHP extension is known-to-be thread-safe. -- justin
Re: Thread-unsafe libraries in httpd-2.0
At 03:04 PM 8/15/2002, Justin Erenkrantz wrote: On Thu, Aug 15, 2002 at 11:51:52AM -0700, Ian Holsman wrote: it's not as obvious, the proposal above forces the developer to say i verify my module will work with threaded No, I'd much prefer that modules code their own checks for it. A simple check in the pre_config hook phase should be sufficient. The answer i verify my module won't work threaded and emitting a warning [or outright error] should be more than sufficient. This allows PHP to collect the extensions it's loading and decide if thread safety is a hazard or those extensions are explicitly trusted for thread safety. I think it's bogus to state that Apache 2.0 is causing the pain. If you don't want to be loaded in a threaded server, say so in your preconfig. There's no reason to bloat all of Apache and it's well behaved modules with extra code, when only a handful of modules care to report that they can't be compiled for a threaded architecture. Justin is right on here. Bill
