httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: Remove prefork MPM.
Date Tue, 11 Jul 2000 20:36:44 GMT
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
> -------------------------------------------------------------------------------
>


Mime
View raw message