httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: Remove prefork MPM.
Date Tue, 11 Jul 2000 20:37:46 GMT


I'm not touching mpmt.c anymore for the next day or two.  Feel free to do
whatever you want in it.

Ryan


On Tue, 11 Jul 2000, Bill Stoddard wrote:

> If you can run the "unified" MPM in pure prefork mode (without relying on pthreads for
> anything) and keep the #ifdefs to a minimum, then I'm +1 on all of this. I pretty much
> agree with you that it is possible to reduce the #ifdefs with a little work.
> 
> While you are monkeying with the MPMs, can you change MaxClients to MaxServers?  The
name
> 'MaxClients' is misleading in the context of the threaded MPMs. I would do it myself
but I
> don't want to get in the way of your work.
> 
> Bill
> 
> > Take a look at the MPMs.  All of the common code that doesn't require
> > global variables has been moved to mpm_common.   If we move any more code
> > to mpm_common.c, we have to open up global variables, which I don't want
> > to do.
> >
> > Then, take a look at mpmt.c.  It's a mess of #ifdefs.  Now, take a closer
> > look.  Most of those can go away with a little bit of elbow grease on the
> > code.  Even the stuff that isn't common code within the Unix MPMs right
> > now, is mostly common concepts, it's just variable names or how the code
> > was written that is different.
> >
> > The scoreboard stuff is a HUGE part of the non-common code in mpmt.c.  If
> > we can finish abstracting that stuff, a big part of the #ifdefs go away.
> >
> > There is a lot of stuff we can do to make more of this code common, but it
> > will take more time.
> >
> > Ryan
> >
> > On Tue, 11 Jul 2000, Greg Stein wrote:
> >
> > > On Tue, Jul 11, 2000 at 10:14:58AM -0700, rbb@covalent.net wrote:
> > > > On Tue, 11 Jul 2000, Rodent of Unusual Size wrote:
> > > >
> > > > > rbb@covalent.net wrote:
> > > > > >
> > > > > > I would like to remove the prefork MPM Tuesday.  Does anybody
have
> > > > > > a problem with that?
> > > > >
> > > > > Yep, I do.  We need to keep a true prefork MPM around, not an
> > > > > emulated one that requires threads and thread locking.
> > > >
> > > > There is no reason to have as much duplicated code as the Unix MPMs
> > > > have.  I can remove most of the duplicated code, but that requires opening
> > > > up a lot of static variables.  The more duplicated code we have, the more
> > > > times we have to fix the same bug.
> > >
> > > Rather than jamming them all together, why not simply create more mpm_common
> > > functions? If they need state, then start passing around the data (instead
> > > of global variables). Or a context structure.
> > >
> > > > I am in the middle of fixing mpmt so that it doesn't require any of the
> > > > threads stuff.  That is an optimization though, and it can wait for a
day
> > > > or two.
> > >
> > > I fear that mpmt.c is going to become unmaintainable because of all the
> > > #ifdef code in there.
> > >
> > > Sharing code through mpm_common seems like the most appropriate solution.
> > >
> > > Cheers,
> > > -g
> > >
> > > --
> > > Greg Stein, http://www.lyra.org/
> > >
> >
> >
> > _______________________________________________________________________________
> > Ryan Bloom                        rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > -------------------------------------------------------------------------------
> >
> 


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message