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