httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: httpd-2.0/server/mpm/perchild config.m4
Date Fri, 16 Feb 2001 17:24:26 GMT

> > > 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
> > > 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 Bloom               
406 29th St.
San Francisco, CA 94131

View raw message