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 >> > >> >
