Hi Bill, I was just worried about forking mpm_prefork into mpm_prefork_buckets, and so on with worker/event/..., most of the code would have been the same.
But I can't disagree with you, factorizing the existing MPMs shared codes (it seems there are quite some) and future ones into a common interface is indeed the way to go. +1 for as much MPM as needed provided minimal code is duplicated. Best regards, Yann. On Thu, Mar 6, 2014 at 5:49 PM, William A. Rowe Jr. <wmr...@gmail.com>wrote: > Yann, > > what you might wish to consider is that each individual MPM may be > compiled alongside the others. If you do a feature select, you are > left with one of the other. > > If it is designed to cohabitate, then it may share sources under the > os/ branch, but can still exist as a separate loadable MPM. Any new > MPM idea with a proper ICLA/CCLA/Code Grant, such that our users can > make the decision for themselves, I expect will be swiftly tested, > benchmarked and perhaps adopted. > > If it is to exist as a replacement of an MPM in the stable 2.4 tree, I > expect it will meet with stiff resistance. Let's work out an > appropriate way to adopt the code? > > Respectfully, > > Bill > > On Thu, Mar 6, 2014 at 8:26 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > > I'm not sure (yet) a new MPM is needed, or rather, multiple new MPMs are > > needed. > > > > The "bucketized" listeners is applyable to all (*nix only?) MPMs, that > would > > lead to as much forks... > > Couldn't new directives be created instead (ServerBucketsNum, Listen > > <ip:port> <ratio>, ...), defaulting to the current behaviour? > > > > > > On Thu, Mar 6, 2014 at 2:49 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> > >> ++1. > >> > >> > >> On Mar 6, 2014, at 3:15 AM, Plüm, Rüdiger, Vodafone Group > >> <ruediger.pl...@vodafone.com> wrote: > >> > >> > > >> > > >> >> -----Original Message----- > >> >> From: William A. Rowe Jr. [mailto:wmr...@gmail.com] > >> >> Sent: Donnerstag, 6. März 2014 06:58 > >> >> To: dev@httpd.apache.org > >> >> Subject: Re: [PATCH ASF bugzilla# 55897]prefork_mpm patch with > >> >> SO_REUSEPORT support > >> >> > >> >> > >> >> If you want to truly re-architect the MPM, by all means, propose it > as > >> >> another MPM module. If it isn't adopted here, please don't hesitate > >> >> to offer it to interested users as separate source (although I hope > we > >> >> find a way to adopt it.) > >> >> > >> >> The idea of different MPM's was that they were swappable. MPM foo > >> >> isn't MPM bar. E.g., worker, prefork, event each have their own > tree. > >> >> Likewise, there is nothing stopping us from having 2, or 3 MPM's on > >> >> Windows, and there is nothing stopping us from stating that there is > a > >> >> prerequisite on a particular MPM of Linux 3.1 kernels or Windows > >> >> 2008+. > >> > > >> > +1 to a new MPM on trunk. This gives it more time to settle and to > >> > stabilize > >> > without disrupting current stuff. And if it is fast and stable it will > >> > certainly > >> > cause the 'older' MPM to drop in userbase :-). > >> > IMHO this would even open a path to 2.4.x provided that we do not need > >> > any other > >> > non backportable changes to do this. > >> > > >> > Regards > >> > > >> > Rüdiger > >> > > >> > > >
