httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Date Sat, 17 Feb 2001 11:28:53 GMT
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
>


Mime
View raw message