You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2001/02/16 06:53:41 UTC
cvs commit: httpd-2.0/server/mpm/perchild config.m4
rbb 01/02/15 21:53:41
Modified: server/mpm/mpmt_pthread config.m4
server/mpm/perchild config.m4
Log:
Remove all instances of apache_apr_flags="--enable-threads" from the
config.m4 files. If we leave those in, then Apache automatically
enables threads for all machines when a threaded MPM is chosen. We want
people to have to force threads for platforms that don't run threads
well (i.e. FreeBSD).
Revision Changes Path
1.11 +0 -1 httpd-2.0/server/mpm/mpmt_pthread/config.m4
Index: config.m4
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/mpmt_pthread/config.m4,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -b -w -u -r1.10 -r1.11
--- config.m4 2001/02/01 21:54:53 1.10
+++ config.m4 2001/02/16 05:53:40 1.11
@@ -1,7 +1,6 @@
dnl ## XXX - Need a more thorough check of the proper flags to use
if test "$MPM_NAME" = "mpmt_pthread" ; then
- apache_apr_flags="--enable-threads"
APACHE_FAST_OUTPUT(server/mpm/$MPM_NAME/Makefile)
1.4 +0 -1 httpd-2.0/server/mpm/perchild/config.m4
Index: config.m4
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/perchild/config.m4,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -b -w -u -r1.3 -r1.4
--- config.m4 2000/12/04 22:33:50 1.3
+++ config.m4 2001/02/16 05:53:41 1.4
@@ -1,7 +1,6 @@
dnl ## XXX - Need a more thorough check of the proper flags to use
if test "$MPM_NAME" = "perchild" ; then
- apache_apr_flags="--enable-threads"
APACHE_FAST_OUTPUT(server/mpm/$MPM_NAME/Makefile)
APACHE_MPM_PTHREAD
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by dean gaudet <dg...@arctic.org>.
in order to make a finely tuned MPM i suspect you'll also need to tune APR
... they depend on each other in subtle ways. such as whether you use
kernel-based threading or kernel/user hybrid threading. i always
envisioned choosing a processing model first and getting a portability
library based on that choice.
-dean
On Fri, 16 Feb 2001, Greg Ames wrote:
> rbb@covalent.net wrote:
> >
> > > 2) use APR threads only
> > >
> > > > everything correctly. The best answer I can come up with is to use APR
> > > > threads in our MPMs, which should make us error out when a threaded MPM is
> > > > chosen without threads in APR.
> > >
> > > This would be option (2). Totally fine with me. APR threads shouldn't be a
> > > large burden over calling the pthread API directly. If it is, then we have a
> > > problem :-)
> >
> > This is a much cleaner solution IMHO. Plus, I am a big fan of making
> > Apache eat our own dog food. We wrote a threading library for APR, Apache
> > should use it. :-)
> >
>
> <puts on performance dude hat>
>
> Please think very carefully about this. MPMs were intended to be finely
> tuned for the platform, and a portability abstraction in their own
> right. It's not clear to me that they need to be built on top of
> another portability layer, no matter how much we like it.
>
> I thought one of the goals for 2.0 was to be able to challenge the high
> end servers in terms of path length and scalability. We don't want to
> eat so much dog food that we go...Arf! Arf! Arf!...when we could be
> screaming.
>
> At the very least, benchmark and post the results before committing,
>
> Greg
>
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by rb...@covalent.net.
> > > This would be option (2). Totally fine with me. APR threads shouldn't be a
> > > large burden over calling the pthread API directly. If it is, then we have a
> > > problem :-)
> >
> > This is a much cleaner solution IMHO. Plus, I am a big fan of making
> > Apache eat our own dog food. We wrote a threading library for APR, Apache
> > should use it. :-)
> >
>
> <puts on performance dude hat>
>
> Please think very carefully about this. MPMs were intended to be finely
> tuned for the platform, and a portability abstraction in their own
> right. It's not clear to me that they need to be built on top of
> another portability layer, no matter how much we like it.
>
> I thought one of the goals for 2.0 was to be able to challenge the high
> end servers in terms of path length and scalability. We don't want to
> eat so much dog food that we go...Arf! Arf! Arf!...when we could be
> screaming.
>
> At the very least, benchmark and post the results before committing,
MPMs were meant to allow us to specify how requests mapped to
threads/processes. They are not a portabillity layer. APR handles all
sorts of portability issues that MPMs shouldn't have to deal with at all.
Right now, BeOS is very similar to either OS/2 or mpmt_pthread (I can't
remember which). It could share that code if we would just use APR
threads. Have you looked at the threading stuff in APR? It is a very
clean abstraction layer, that really doesn't add any overhead.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by Greg Ames <gr...@raleigh.ibm.com>.
rbb@covalent.net wrote:
>
> > 2) use APR threads only
> >
> > > everything correctly. The best answer I can come up with is to use APR
> > > threads in our MPMs, which should make us error out when a threaded MPM is
> > > chosen without threads in APR.
> >
> > This would be option (2). Totally fine with me. APR threads shouldn't be a
> > large burden over calling the pthread API directly. If it is, then we have a
> > problem :-)
>
> This is a much cleaner solution IMHO. Plus, I am a big fan of making
> Apache eat our own dog food. We wrote a threading library for APR, Apache
> should use it. :-)
>
<puts on performance dude hat>
Please think very carefully about this. MPMs were intended to be finely
tuned for the platform, and a portability abstraction in their own
right. It's not clear to me that they need to be built on top of
another portability layer, no matter how much we like it.
I thought one of the goals for 2.0 was to be able to challenge the high
end servers in terms of path length and scalability. We don't want to
eat so much dog food that we go...Arf! Arf! Arf!...when we could be
screaming.
At the very least, benchmark and post the results before committing,
Greg
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by rb...@covalent.net.
On Fri, 16 Feb 2001, Rodent of Unusual Size wrote:
> rbb@covalent.net wrote:
> >
> > The problem is that Apache has, in the past, had to determine it's
> > threading situation before running APR's configure script.
>
> Um, bzzzt, did we not decide long long ago that APR *always* had
> to be configured first so that it knew the platform's featureset?
Regardless of what was decided, I was explaining what has been
happening. It may be wrong, and it may not be what was decided, but it is
what was happening. Last night, I began to fix it. We are about half-way
there now.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> The problem is that Apache has, in the past, had to determine it's
> threading situation before running APR's configure script.
Um, bzzzt, did we not decide long long ago that APR *always* had
to be configured first so that it knew the platform's featureset?
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by rb...@covalent.net.
On Fri, 16 Feb 2001, Greg Stein wrote:
> On Thu, Feb 15, 2001 at 10:00:51PM -0800, rbb@covalent.net wrote:
> > On 16 Feb 2001 rbb@apache.org wrote:
> >
> > This doesn't work as well as I would like it to, because mpmt_pthread and
> > dexter are using pthreads instead of APR threads. If we were using APR
> > threads, we would get all sorts of compile time errors. Since we are
> > using pthreads, and Apache detects threads on the system, we setup
>
> "and Apache detects threads on the system" ... that is the problem :-)
>
> Apache shouldn't use the APR thread detection M4 files. It should do one of
> two things:
>
> 1) use threading values exported by APR
The problem is that Apache has, in the past, had to determine it's
threading situation before running APR's configure script. That can
probably be changed now, but I don't believe that is the solution we want.
> 2) use APR threads only
>
> > everything correctly. The best answer I can come up with is to use APR
> > threads in our MPMs, which should make us error out when a threaded MPM is
> > chosen without threads in APR.
>
> This would be option (2). Totally fine with me. APR threads shouldn't be a
> large burden over calling the pthread API directly. If it is, then we have a
> problem :-)
This is a much cleaner solution IMHO. Plus, I am a big fan of making
Apache eat our own dog food. We wrote a threading library for APR, Apache
should use it. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Feb 15, 2001 at 10:00:51PM -0800, rbb@covalent.net wrote:
> On 16 Feb 2001 rbb@apache.org wrote:
> > rbb 01/02/15 21:53:41
> >
> > Modified: server/mpm/mpmt_pthread config.m4
> > server/mpm/perchild config.m4
> > Log:
> > Remove all instances of apache_apr_flags="--enable-threads" from the
> > config.m4 files. If we leave those in, then Apache automatically
> > enables threads for all machines when a threaded MPM is chosen. We want
> > people to have to force threads for platforms that don't run threads
> > well (i.e. FreeBSD).
>
> This doesn't work as well as I would like it to, because mpmt_pthread and
> dexter are using pthreads instead of APR threads. If we were using APR
> threads, we would get all sorts of compile time errors. Since we are
> using pthreads, and Apache detects threads on the system, we setup
"and Apache detects threads on the system" ... that is the problem :-)
Apache shouldn't use the APR thread detection M4 files. It should do one of
two things:
1) use threading values exported by APR
2) use APR threads only
> everything correctly. The best answer I can come up with is to use APR
> threads in our MPMs, which should make us error out when a threaded MPM is
> chosen without threads in APR.
This would be option (2). Totally fine with me. APR threads shouldn't be a
large burden over calling the pthread API directly. If it is, then we have a
problem :-)
> That work will have to wait for a few days/weeks, but it should be noted,
> so I will be putting a note in STATUS right now.
Coolness.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by rb...@covalent.net.
On 16 Feb 2001 rbb@apache.org wrote:
> rbb 01/02/15 21:53:41
>
> Modified: server/mpm/mpmt_pthread config.m4
> server/mpm/perchild config.m4
> Log:
> Remove all instances of apache_apr_flags="--enable-threads" from the
> config.m4 files. If we leave those in, then Apache automatically
> enables threads for all machines when a threaded MPM is chosen. We want
> people to have to force threads for platforms that don't run threads
> well (i.e. FreeBSD).
This doesn't work as well as I would like it to, because mpmt_pthread and
dexter are using pthreads instead of APR threads. If we were using APR
threads, we would get all sorts of compile time errors. Since we are
using pthreads, and Apache detects threads on the system, we setup
everything correctly. The best answer I can come up with is to use APR
threads in our MPMs, which should make us error out when a threaded MPM is
chosen without threads in APR.
That work will have to wait for a few days/weeks, but it should be noted,
so I will be putting a note in STATUS right now.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Posted by rb...@covalent.net.
On 16 Feb 2001 rbb@apache.org wrote:
> rbb 01/02/15 21:53:41
>
> Modified: server/mpm/mpmt_pthread config.m4
> server/mpm/perchild config.m4
> Log:
> Remove all instances of apache_apr_flags="--enable-threads" from the
> config.m4 files. If we leave those in, then Apache automatically
> enables threads for all machines when a threaded MPM is chosen. We want
> people to have to force threads for platforms that don't run threads
> well (i.e. FreeBSD).
This doesn't work as well as I would like it to, because mpmt_pthread and
dexter are using pthreads instead of APR threads. If we were using APR
threads, we would get all sorts of compile time errors. Since we are
using pthreads, and Apache detects threads on the system, we setup
everything correctly. The best answer I can come up with is to use APR
threads in our MPMs, which should make us error out when a threaded MPM is
chosen without threads in APR.
That work will have to wait for a few days/weeks, but it should be noted,
so I will be putting a note in STATUS right now.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------