On Thu, Dec 3, 2015 at 3:40 PM, Jim Jagielski <[email protected]> wrote:
> > > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr <[email protected]> > wrote: > > > > My personal wish list is that we eliminate module bloat by coalescing > > alternative "standard" implementations into a single module again in > > 2.next, and not just limited to lbmethod, but also the core socache > > and slotmem providers. Most stock/core implementations shouldn't > > change if a user wants to plug in 'yet another' option, but there is > really > > no excuse for us to map so many ldobjects and text pages into the > > memory map of a given process, when the actual program text page > > of each is a few hundred opcodes, max. > > > > Not following you there... what do you mean? You mention the > lbmethods; do you mean instead of having each method be its > own module, making them all one? > Not specific to lbmethods but yes, one mod_lbmethod_core.so provider of the basic set of 3-4 methods that right now eat up a lot of 64kb process page mappings for no particular benefit. The builder could even decide these are compiled-in to the base httpd. We don't dismiss the loadable approach, we simply decide this subset is effectively baked, and then use the loadable lbmethod to extend yet another experimental/dynamic/evolving method, from the ASF or third parties.
