You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/08/15 18:27:57 UTC
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
Posted by Greg Ames <gr...@apache.org>.
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
Posted by Brian Pane <br...@apache.org>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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
Posted by Greg Marr <gr...@alum.wpi.edu>.
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
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: Thread-unsafe libraries in httpd-2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
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.
--
#ken P-)}
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
Posted by Scott Hess <sc...@avantgo.com>.
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
Re: Thread-unsafe libraries in httpd-2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Re: Thread-unsafe libraries in httpd-2.0
Posted by Justin Erenkrantz <je...@apache.org>.
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
Posted by Ian Holsman <ia...@apache.org>.
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
Posted by Justin Erenkrantz <je...@apache.org>.
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
Posted by "johannes m. richter" <jo...@gmx.net>.
>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
Posted by Ian Holsman <ia...@apache.org>.
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
Posted by Wilfredo Sanchez <ws...@mit.edu>.
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
Posted by Ian Holsman <ia...@apache.org>.
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
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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
Posted by Justin Erenkrantz <je...@apache.org>.
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
Posted by Rasmus Lerdorf <ra...@apache.org>.
> 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
Posted by Ben Laurie <be...@algroup.co.uk>.
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.
>
> 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.
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.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
Available for contract work.
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Thread-unsafe libraries in httpd-2.0
Posted by Rasmus Lerdorf <ra...@apache.org>.
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
Posted by Greg Stein <gs...@lyra.org>.
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
Posted by Justin Erenkrantz <je...@apache.org>.
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
Posted by Rasmus Lerdorf <ra...@apache.org>.
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